Re: [lfs-support] LFS-7.2 with RPM
On 03/01/2013 08:15 PM, Baho Utot wrote: FYI - For those that may be interested. I have just finished my current project, building LFS using the RPM package manager. It builds the LFS tool chain from bash scripts, then RPM is build and installed into /tools, which I then use to build chapters 6-8 using RPM driven by some bash scripts. The whole build is controlled by a single bash script, so that once the environment is setup, running the control script will build LFS in one go. Set the root passwd and then reboot to the newly built system. I have uploaded it to github. Here is the URL: https://github.com/baho-utot/LFS-RPM Did you give up on Pacman? -- DJ -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] chapter06 glibc
On 01/30/2013 06:50 PM, Bruce Dubbs wrote:
Yusuf Yılmaz wrote:
gawk already installed. i think the problem on chroot system. cause on the
host system:
export test=asd
echo $(test)
runs success but on chroot lfs system
it gives this error:
root:/# export test=asd
root:/# echo $(test)
bash: command substitution: line 3: syntax error near unexpected token `)'
bash: command substitution: line 3: `test)'
Your syntax is wrong. You want:
echo ${test}
Variable substitution is done with braces, {}, not parentheses ().
-- Bruce
Actually, that should still work in bash...just not on the variable
named test, but on the test executable (actually the built-in IIRC). The
output should be a single blank line. I vaguely remember seeing this
behavior myself a long time ago, but don't recall the cause. Best guess
is Armin's suggestion, followed by patches not applied correctly, but
I'm not certain. Either way, the interpreter being used now is broken.
Backtick (`) syntax will probably still work for the test case, but that
doesn't really do anything for the OP. The chapter 5 bash is broken and
must be rebuilt.
-- DJ
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Packaged LFS-6.8
On 09/06/2012 06:51 AM, Baho Utot wrote: On 09/05/2012 11:26 PM, DJ Lucas wrote: On 08/24/2012 10:35 AM, Baho Utot wrote: I have successfully packaged LFS-6.8 using pacman from arch linux. Here is the link if anyone is interested and wants to have a look. https://github.com/baho-utot/LFS-pacman I am going to update that repository to versions 7.0 7.1 and 7.2. The build system I use for the tool chain chapter 5 could be adapted to the base chapter 6. I think it is a easy way to script a build. Comments welcome Cool. Thanks for doing this. Working from trunk as of an hour ago now. I've also just forked your github to work for update to SVN along with some other changes for my own taste. I've not worked with Pacman yet, though I had intended to replace my aging homebrew packaging system for some time now...seems as good a time as any. Will let you know how it turns out when completed. -- DJ Lucas OK thanks I have tagged lFS-6.8 to 7.1. I am working on LFS-7.2 now and plan to have it complete by the first of next week if all goes well. I am on 6.8 Sed Sweet. I'll delete the fork and wait it out then as I had other stuff come up and wasn't able to work on it more than updating the package versions and md5s (not the build instructions). There are some changes that I'll be making locally, just adding BLFS packages that affect the base packages (ACL, ATTR, bc, Coreutils, Cracklib, Linux-PAM, OpenSSL, Python, Shadow, and Util-Linux off the top of my head). -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Packaged LFS-6.8
On 08/24/2012 10:35 AM, Baho Utot wrote: I have successfully packaged LFS-6.8 using pacman from arch linux. Here is the link if anyone is interested and wants to have a look. https://github.com/baho-utot/LFS-pacman I am going to update that repository to versions 7.0 7.1 and 7.2. The build system I use for the tool chain chapter 5 could be adapted to the base chapter 6. I think it is a easy way to script a build. Comments welcome Cool. Thanks for doing this. Working from trunk as of an hour ago now. I've also just forked your github to work for update to SVN along with some other changes for my own taste. I've not worked with Pacman yet, though I had intended to replace my aging homebrew packaging system for some time now...seems as good a time as any. Will let you know how it turns out when completed. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Filesystem changes and systemd
On 07/24/2012 06:14 PM, Baho Utot wrote: When I finish my project I would like to dive into the init scripts and see if I can make them LSB compliant. Already done. You only need to add initd-tools from BLFS for the bootscripts part of LSB. There are other things, such as at and rpm for instance, or the runscripts for fcron (to handle hourly, daily, weekly, monthly directories) but for the most part, we are pretty close to compliant. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] pam_ck_connector and pam_loginuid
pam_ck_connector and pam_loginuid should not be placed into
system-session, but rather directly in login, {g,k,x}dm, sshd, etc. as
session optional. These modules are only intended for login sessions.
When using sudo, pam_ck_connector causes gnome-shell to segfault. I
don't completely understand the interaction just yet, but I suspect it
has something to do with root now owning the session cookie. :-)
I think the best solution would be to create empty login-*
configurations and append to those (include them by default in login
configuration), and then include that into login utilities pam
configuration. I'll try and get a look at it Wed night or so (maybe even
tonight...we'll see).
-- DJ Lucas
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Reduce Size Of LFS Build
On 04/10/2012 02:10 AM, Kshitij Jain wrote: Hi I am a student and working on building LFS as a project I have already build the Linux but i want to reduce the size of the system to minimum. Can u please suggest me ways to reduce the size of LFS. Your question is a bit ambiguous. The solution really depends on the goal of the system. Take an embedded system for example. You would likely want to use uClibC as suggested by Firerat, but busybox is certainly a matter of taste. It may actually be more responsible to build the few utilities you need linked statically and forgo the typical environment completely. At an absolute minimum, you need only a kernel and a statically linked binary to run as init (granted, it wouldn't be very functional), but a kernel with no modules, a statically linked ash or dash, and a supported file system (with static device nodes) do equate to a functional (read-only) system. In fact, we used to use this method many many moons ago for LFS itself. The first test reboot of LFS had only sysvinit and bash statically linked, and that could have easily been reduced to just bash if desired (either 'ln -s /bin/bash /sbin/init' or init=/bin/bash in LILO). Yes, I had to review 1.0 (which I never completed) to remember exactly how it was done. http://archive.linuxfromscratch.org/lfs-museum/1.0/LFS-HOWTO-1.0-HTML/ -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Package management
On 03/25/2012 10:04 PM, Eleanore Boyd wrote: Has anyone thought of this: when you download a package, store it in the sources folder used for building the system, and organize it to personal preferences and tastes? That way, if you need to reinstall a package, you still have the tarball it was installed from, and you can see your installed packages quickly and easily according to your preferred organization without relying on somewhat arbitrary definitions of the appropriate categories of other people. It seems like a good idea to me, anyway. And no, I don't really have a better way of explaining it, as I would lose my life if it depended on me explaining why I shouldn't be dead. Or am I giving out the idea on the wrong list? This is the second email I've sent in the same day, and I normally don't send emails.. Elly In the day of multi-terabyte drives, I would think it unlikely that any of us delete the source archives after they are installed. Unless you keep the instructions as well, I would hardly call it package management, and even that is a stretch for me, but your distro, your rules. :-) It's all about personal choice, and if that is sufficient for you, great! As for me, I do things a couple of different ways depending on the goal of the system. On my desktops, I use a pair of custom scripts, something similar to the install-log method, it goes a bit further to aid in book development (download, check MD5, touch all files after extraction, log the instructions used and the build output, determine SBU and disk usage, flag modified files, etc.). It's a little outdated, and has been in a constant state of flux for the past several years. I break it from time to time, but it has served me well because it was written and molded over time into my perfect idea of management for a development system. I simply don't see a purpose for archiving everything on a development system...should I trash it, I either fix it manually, or start over. On my servers, save for one outstanding that is in the process of being replaced (which I am absolutely afraid to touch), everything is installed to DESTDIR (or equivalent) and packaged up as a tar.bz2 (guess I should probably use xz now) and then manually installed from there, along with something similar to, but not as verbose, as above. When I update a package, the original binaries are kept indefinitely. I've even once delved into RPM, wrote a bunch of helper scripts to make it easier, but in the end, it was just a bit too unintuitive (??) for my taste. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] looking for a build buddy
On 01/29/2012 12:00 PM, Robert A. Lerche wrote: Hi. I have previously built LFS and used the LFS Live CD project to create a custom system (back in the 6.3 / 6.4 days). I am now engaged in a project for a client using Android on a custom embedded system. As you may know, Android uses the Linux kernel as a base. Has anyone out there built Android completely from sources? Yes, even been through the joy of adding a new device at one point, though people much smarter than I have superseded anything I might have accomplished in my own impatience. Took me several hours to figure out how to get the sucker to boot the first time. I'd appreciate a chance to chat with someone familiar with setting up a complete source build environment. See the IRC link below if you'd prefer direct chat to others methods of information gathering... Thanks in advance. While the final product is not even remotely similar to LFS, you will still find quite a bit in common with LFS in that massive 6GB source tree, but still way more differences. You will need a proper mult-lib setup on your build host, however, which renders LFS proper useless for Android development. See CLFS if you really want to use *LFS as a build host. I use Ubuntu in a VM myself. It's not terribly difficult to build a cross toolchain from scratch either should you need it for projects outside the tree, see codesorcery's open source changes. IMO, the biggest pain of building android is learning to use the repo script instead of git by itself. You are actually pulling code from from around 200 (or potentially more) git repositories for the Android source tree. The repo tool attempts to simplify that a bit, keeping a manifest file which describes all of the various git repos and local paths, but it, like any other tool, has a couple of gotchas. Do not try and change the path after you have done an init, remove the entire tree and start from scratch. Also, make sure it is more than one path element deep below your home directory...use something like ~/Android/AOSP and ~/Android/Evervolv, not ~/AOSP and ~/Evervolv. If you ignore this last bit, you won't like the result when you elect to remove one of the trees by choice, followed by the other as necessity (note that git itself will still work correctly so that you can push your changes back to github, or wherever). I never did dig in and figure out the cause, but it does not make a happy developer when it fails (and gives weird errors as well, usually revolving around the .repo directory). As mentioned by another poster, CyanogenMod has a great wiki and could be used as a good starting point I suppose, but they are maintaining something like 70+ devices now and have many many differences to AOSP. If you are looking for examples, I think I'd look at a project that manages less devices (Evervolv is one I follow and much much closer to AOSP proper) for figuring out custom device profiles (and mealtime functions (lunch/brunch) which are heavily modified in CM's repos). Probably look for something with similar hardware to your new target and go from there. Just about everyone uses github, so remember to include it in your search terms if looking for direction. Links: I'm sure you've found this one already, at least I hope you have: http://source.android.com/source/downloading.html CodeSorcery (custom cross toolchain, not actually needed unless you intend to develop in C outside of the Android source tree, probably just use the one in git): http://www.mentor.com/embedded-software/android/ CyanogenMod (great documentation, but probably overkill as a source for creating a new device tree): https://github.com/cyanogenmod http://wiki.cyanogenmod.com/index.php?title=Main_Page They also have a freenode IRC channel for developers, but I don't know it off the top of my head. Some really smart people in there too. Evervolv (one suggestion for example code for a new device tree (in addition to the ones already in AOSP, there are many others out there as well, but these guys tend to keep it simple enough, and the devs on IRC will likely bend over backwards to help): https://github.com/Evervolv http://wiki.evervolv.com/index.php/Main_Page irc://irc.freenode.net/#evervolv Hope that gets you going in the right direction. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Ok, now I am having issues
On 11/08/2011 10:51 AM, Bruce Dubbs wrote: Andrew Benton wrote: On Tue, 8 Nov 2011 07:04:54 -0600 William Immendorfwill.immend...@gmail.com wrote: (Bruce, you may want to add:) The LiveCDs of these distributions work well as a base system too. As others have said, they may need some tweaking (/bin/sh = bash, gawk, etc) That's true. Also they are somewhat more difficult to use. The binaries take a long time to load off the dvd/cd and you have to repeat any configuration changes upon reboot. I think it better to not suggest/encourage LiveCD use, although it is possible. -- Bruce IDK, I used the Gentoo Live DVD for a bare metal install the other day...it works out of the box without any tweaks. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: trouble compiling glibc in chapter 6.9
On 09/25/2011 10:06 AM, Dustin Essington wrote: I've had next to no trouble, minus missing or miscopying a step, up to this point. I've removed the glibc-2.13 and glibc-build dirs and tried this step a few times, even left it alone for 6 hours, but it always ends up in a loop. I've attached a copy of the output. Seen this a few times over the past couple of months with various causes. Double check that both the date and time are set correctly. If not that, then perhaps this: http://www.linuxfromscratch.org/pipermail/lfs-support/2010-December/040001.html -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LFS SVN
On 09/05/2011 01:32 AM, Tyler McMaster wrote:
grub-install /dev/sda
UBUNTU VERSION 10.04 LiveCD
Latest SVN
Grub is not installed because Ubuntu is liveCD.
Partitions? Ext3, Swap
The base system is built. I just need the boot loader to be installed so
I can customize it further.
Still not enough information. Think your doctor would be able to help if
you told him My leg hurts? You might get a script for the latest fad
pain killer depending on the level of professionalism of the doctor, but
it wouldn't do a darn thing to fix the problem if you've broken your leg!
We'll need to see the _exact_ commands issued and the _exact_ error
message returned. If you are unable to copy and paste for whatever
reason, you can try and use redirection as opposed to manual typing and
attach the file, for example:
root:/etc/sysconfig# grub-mkconfig -o somefile 21 | tee test.txt
Generating grub.cfg ...
cat: /boot/grub/video.lst: No such file or directory
done
root:/etc/sysconfig# cat test.txt
Generating grub.cfg ...
cat: /boot/grub/video.lst: No such file or directory
done
root:/etc/sysconfig#
You mentioned (literally) something about blocklists in your original
message, so it sounds possible that grub thinks that /dev/sda has no
partitions on it. Maybe double check that all of the virtual file
systems (/sys /proc /dev{,shm,pts}) are mounted, but that could be a
wild goose chase given what little info you've provided.
-- DJ Lucas
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: LFS SVN
On 09/05/2011 12:59 PM, Bruce Dubbs wrote: You still don't tell us the command you used. I assume that it was: grub-install /dev/sda What was the result of 'cat device.map'? Is /dev mounted in chroot? What is the result (in chroot) of 'fdisk -l' Also, please include the output of 'mount' from the host system. It sounds like you created a filesystem dirctly on /dev/sda or /dev/sda contains only logical partitions...or more likely that grub is simply confused. I'm hoping for the latter, but there is a nasty workaround for the former (involving the error message you are receiving) if you've incorrectly partitioned your drive. BTW, is this possibly in a VM? -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: network interface eth0 doesn't exist while booting up LFS
On 09/03/2011 11:00 AM, Karthik Bhuvanagiri wrote: Hi, I did as u said but not resolved my problem - problem still exists. ip link command shows up following thing aprt from loopback interface: 2: sit0: NOARP mtu 1480 qdisc noop state DOWN link/sit 0.0.0.0 brd 0.0.0.0 I recompiled the kernel by choosing appropriate networkcard device driver, installed and rebooted. Still shows up interface eth0 interface doesn't exists while booting up. Please trim previous responses to relevant info and post your reply below the quoted text so that a logical time line is formed in the thread. As to your problem, did you build the driver into the kernel or as a module? If the interface worked in the host system, please boot into your host system and post the output of lspci and lsmod. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LFS-6.8 - 5.10. GCC-4.5.2 - Pass 2
On 08/22/2011 04:58 PM, scrat wrote: I am having some issues with building GCC-4.5.2 - Pass 2. I am using Arch linux i686 for the host system and building for i686. When I use the following from the book CC=$LFS_TGT-gcc -B/tools/lib/ \ AR=$LFS_TGT-ar \ RANLIB=$LFS_TGT-ranlib \ ../$pkgname-$pkgver/configure \ --with-local-prefix=/tools \ --enable-clocale=gnu \ --enable-shared \ --enable-threads=posix \ --enable-__cxa_atexit \ --enable-languages=c,c++ \ --disable-libstdcxx-pch \ --disable-multilib \ --disable-bootstrap \ --disable-libgomp \ --with-gmp-include=$(pwd)/gmp \ --with-gmp-lib=$(pwd)/gmp/.libs \ --without-ppl \ --without-cloog make -j3 I get the following result: /mnt/lfs/tools/bin/../lib/gcc/i686-lfs-linux-gnu/4.5.2/../../../../i686-lfs-linux-gnu/bin/ld: cannot find crti.o: No such file or directory /mnt/lfs/tools/bin/../lib/gcc/i686-lfs-linux-gnu/4.5.2/../../../../i686-lfs-linux-gnu/bin/ld: cannot find -lc /mnt/lfs/tools/bin/../lib/gcc/i686-lfs-linux-gnu/4.5.2/../../../../i686-lfs-linux-gnu/bin/ld: cannot find crtn.o: No such file or directory collect2: ld returned 1 exit status make[3]: *** [libgcc_s.so] Error 1 make[3]: Leaving directory `/mnt/lfs/build/tools/gcc-pass-2/gcc-build/i686-pc-linux-gnu/libgcc' make[2]: *** [all-target-libgcc] Error 2 make[2]: Leaving directory `/mnt/lfs/build/tools/gcc-pass-2/gcc-build' make[1]: *** [all] Error 2 make[1]: Leaving directory `/mnt/lfs/build/tools/gcc-pass-2/gcc-build' crti.o and crtn.o are in the proper place /tools/lib as per ls /tools/lib and yep they are there. It seems you have already found the problem I did some looking around and and I see that CC=$LFS_TGT-gcc -B/tools/lib/ \ should have resulted in those libs being found. When I add --prefix=/tools \ to the above at the configure step and gcc complied and linked successfully ( as much as I can tell ) . All the chapers leading up to this point are good...I get the result that the book says I should...again as far as I can tell. Your command above is not consistent with the book. You were supposed to add --prefix=/tools to the configure command if following the book. What is the --with-local-prefix=/tools \ really do, I haven't come to grips with that yet/ That removes /usr/local/include form the search path. I do know what --prefix=/tools is about I am good to go with gcc or did I make a mess? Unless you are doing something that is not consistent with the book, for whatever reason, you are good. Comments/help/flames/etc welcome. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Question about the 'K' and 'S' in script names in /etc/rc.d/rc{0, 6}.d
Moved to LFS-Dev.
On 07/17/2011 07:57 PM, Bruce Dubbs wrote:
DJ Lucas wrote:
On 07/17/2011 02:51 PM, Bruce Dubbs wrote:
DJ Lucas wrote:
Actually, this check needs to be removed. It causes issues for the alsa
script and also setclock (if used to set hwclock when network goes down
in RL2).
Wouldn't this be just as easy as creating symlinks S50setclock in rc0
and rc6 in the LFS Makefile? In the same way, creating S35alsa symlinks
in the BLFS Makefile would save the asla settings.
No. Drop to RL1 with alsa volumes restored via udev for an example of
why that block should be removed. It doesn't matter for 0 and 6 because
the check is skipped. It's been a while, but IIRC, the same thing for a
K??setclock link in RL2.
I don't understand. What we have now is:
snip code
In rc1.d I have K30sshd, K80network, K90sysklogd, S25random. The same
in rc2.d. setclock is executed in rcsysinit.
If alsa utils is installed, you should have K links in RLs 0,1,2,6 and
no start links as the volume restore is handled by udev.
If I add S50setclock and S40alsa to rc{0,6}.d, the '-f ${prev_start}'
fails and the continue is never executed. The command is run with the
stop parameter in both cases and does the right thing, AFAICT.
Oh, actually, setclock should not be run in rcsysinit any longer. that's
for udev to handle now as well. That is where the issue comes into play.
The alsa script should write the volumes to disk when switching from
runlevel 3 to runlevel 2 (no net == no usr == no alsactl) or especially
RL1 as the rootfs might be RO, and it certainly wasn't started by a
script in RL3, but by udev (please ignore the FHS /usr argument as we
are still bound by it for now). You should see the same issue (not
started in previous runlevel) if you were to put Kxxsetclock in rc2.d or
rc1.d and telinit 2 or 1.
This is proper IMO when using NTP, but not really useful in practice.
Agree, except if the hw clock is too far off, ntp is unhappy.
That is the point, to set hwclock when dropping network so that it'll be
that much closer when you jump back into 3/4/5probably really
doesn't matter unless you are in RL2 overnight and system timer is way
outta whack (in which case you have bigger problems).
Are you suggesting that we just remove the 'if' block above? I'd think
that might add some strange failures at shutdown, but shouldn't hurt
anything.
Yes, that is exactly what I was suggesting. Using S links in 0 and 6 for
alsa does nothing for RL1 and RL2. Besides, as mentioned earlier in the
thread, the S links in 0 and 6 _were_ intended to be reserved for very
specific system requirements. I'm not really sure if ALSA, or anything
outside of the base LFS for that matter, should get special treatment here.
With the LSB defined return values, it didn't matter because stopping an
already stopped service results in a return value of 0 (an OK message).
In the case of alsa, this doesn't even apply, you're not stopping a
service, only writing a file, there should never be a failure here
unless it is run late or you did something that makes /etc read only.
Also, I don't really see how we could get a bunch of warning/error
messages with current scripts (though I haven't really used the stock
scripts for more than a few minutes at a time since 2006). Everything
installed by the books is handled in all 7 runlevels or sysinit, with a
few exceptions, notably the two above (and only alsa is mentioned in
either of the books).
The prevlevl check has simply been outdated by modern tools (udev).
Going back to the LSB return values mentioned above, the warning
messages about items not running at shutdown are not really useful. I
mean, what can you do about it at that point? Same thing for the not
started in previous runlevel message...just exit 0 and paint a pretty
green message on the screen. If the pid file checks are rewritten, again
I'll refer to the LSB scripts pidofproc(), you can simply bypass the
execution and exit 0. This also fixes the issue with the apache script
killing children first.
Again, I don't particularly like it (yet), but I have a feeling that
we'll begin to see more and more of this in the future. Network cards
could conceivably be next in line (think of turning on your wireless
card on your laptop), so it makes some sense to rewrite ifup and ifdown
now, along with the network script (which could be also be replaced by
NM or something similar after LFS). As much can be reused in the future,
the better. Of course, I could be very wrong in my prediction, but I
figure rather than introduce a couple of corner cases, you should
probably go ahead and nip what we can in the bud now while you are
familiar with the work that needs to be done.
Free time is still not what it should be for me right now, but I'll jump
in an make some comments on your changes (if needed/wanted) as soon as I
have time to install and test.
-- DJ Lucas
--
http
Re: Question about the 'K' and 'S' in script names in /etc/rc.d/rc{0, 6}.d
On 07/12/2011 06:19 AM, Theodore You wrote: On Tue, Jul 12, 2011 at 9:47 AM, Bruce Dubbsbruce.du...@gmail.com wrote: Theodore You wrote: The book says in chapter 7.3: Links that start with an S in the rc0.d and rc6.d directories will not cause anything to be started. They will be called with the parameter stop to stop something. If so, why are there still scripts starting with an S in these two directories? Why not change all S to K? When changing to any run level, the rc script is run. It goes through the K entries with a stop. For runlevels 0 and 6, all the S entries are also run, in order, with a stop. For runlevels 1-5, The S entries are run with a start. According to the rc script, if an S entry was started in previous runlevel, and not stopped in current runlevel, it will be skipped, but if we are switching to runlevel 0 or 6, this script won't be stopped. Is this intended or I'm wrong? Actually, this check needs to be removed. It causes issues for the alsa script and also setclock (if used to set hwclock when network goes down in RL2). For runlevels 0 and 6, this lets us shut down in the order started (K entries) and then run the S entries, in order, to actually halt or restart the system. If we want to change the order of these scripts, we can simply change the number of the script, I still think there's no need for the S. There is no real _need_ for S links in 0 and 6. What it provides is a failsafe of sorts. Nothing outside of system software should ever put a start link in 0 and 6 ensuring that the last few scripts are run last (sendsignals, mountfs, and reboot/halt IIRC). -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Question about the 'K' and 'S' in script names in /etc/rc.d/rc{0, 6}.d
On 07/17/2011 02:51 PM, Bruce Dubbs wrote: DJ Lucas wrote: Actually, this check needs to be removed. It causes issues for the alsa script and also setclock (if used to set hwclock when network goes down in RL2). Wouldn't this be just as easy as creating symlinks S50setclock in rc0 and rc6 in the LFS Makefile? In the same way, creating S35alsa symlinks in the BLFS Makefile would save the asla settings. No. Drop to RL1 with alsa volumes restored via udev for an example of why that block should be removed. It doesn't matter for 0 and 6 because the check is skipped. It's been a while, but IIRC, the same thing for a K??setclock link in RL2. This is proper IMO when using NTP, but not really useful in practice. I don't do this any longer, but with the gradual change to udev scripts handling start up items instead of boot scripts for specific hardware (this will likely happen whether we like it or not), it would probably be good to be prepared for it (not to mention the alsa breakage that is there now). -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: 2.6.39 - mount /dev/fd0 no longer works
On 06/04/2011 09:58 AM, al...@verizon.net wrote: Hi DJ, First off. At (B)LFS, to which I've belonged for many years now, I met only nice people and whether volunteer or not, many high quality professionals. You, in particular, are at the top of my list. Period. Well thank you very much! What has gotten to me is the amateurism, mis-coordination and the ensuing constant and disgusting cover-up that has reached the highest levels of open source production (witness this incident, the settle in udev-168, Firefox-4.0 and -3.6.14, etc.). Yes, these are all good examples...but see below. It's possible that, what with the recent and projected technological directions the world has taken, more people have started to see Linux as really irrelevant now and jumped ship (in the water or to other vistas and endeavors du jour). I actually see it exactly the opposite. It's maybe a seemingly insignificant development - ironically, some poetic justice after years of constantly trashing the enemy - to find the Home button at the right on the new Firefox. Is that a white flag or what? IDK, I just don't see it as a white flag. It really depends on how the majority of users exercise the software. I seriously doubt that the the change in question was simply committed without consideration of user habits. I think it is safe to say that you can't please everyone, so you simply have to go with the preferences of the majority. Keep in mind that in recent years, there has been a large influx of of former Windows users jumping ship to easy distros like Ubuntu. Opposite vantage point. I know for a fact that I am partially responsible for this trend. Mom, Dad, Kids, Aunts, Uncles, Cousins, quite a few of my friends, and if my grand parents were still around, they'd be on it too. This alone could account for the move of the home button. To be honest, I hadn't even noticed (I rarely use the home button). Consistency across platforms is also a concern of the Mozilla projects, I mean they have 6 (more?) major environments to support, and no matter which OS I happen to be using at the time, I can expect a relatively consistent user experience, save for the location of the close, maximize/restore, minimize, and (if supported) iconify buttons. That, at least to me, is pretty impressive given the major differences in those environments. If there is an AT, and there is one, it is clearly pointed at the _indifference_ shown by (B)LFS denizens at recent open source issues I alluded to (or had in mind). To see it more clearly, simply imagine one of Window$ iterations just dropping the floppy enumeration at one point. All Seattle area would've been gutted by fire in an instant. I disagree. In fact, it is in process already in the Windows operating system. For instance, the F6 prompt can now be answered with a USB key. I suspect the indifference can be answered by this very example of the floppy drive. The mass majority of users simply have no use for a floppy now days. I think I might still have a couple of MFM HDDs and a controller out in my shed, think those are still supported? I haven't the slightest clue how to marry them anymore. In fact, I don't even have a single PC that they could be used in (ISA). While I agree that there has been a problem with release quality as of late, given the examples above, I don't really consider it a severe problem in the grand scheme of things (see below for why). But then again, as I said, all may be excused and ascribed to the new attractions in town (and there are many and _valid_) luring people away from demanding the best (or at least a reasonable level of excellence) in Linux. I suppose we just have a different vantage point. I see it as normal growing pains. As you mentioned above, many valid changes are coming down the pipe to modernize the OSes--unfortunately for maintainers, it seems that the flood gates have been opened. For a number of reasons, these oversights are likely to occur with more frequency for a short time, it is just relative to the number of changes occurring. On a positive note, just keep in mind that oversights like these are embarrassing to the developers, and you can bet that QC changes will occur upstream to keep these same mistakes from happening again, which I consider a positive change. IDK, I guess I just tend to see the positives over the negatives in most cases, though, like most, I am definitely more vocal about the negatives. At any rate, things will settle down soon enough, but hopefully not *too* soon. :-) -- DJ Lucas -- 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-21010424)
On 04/28/2011 03:04 PM, bsquared wrote: Your message reminded me to look into it and here's what I found... excerpt from http://www.linuxfromscratch.org/hints/downloads/files/time.txt; ~ Next are the symlinks. The symlink to run the setclock script is already ~ present in /etc/rc.d/rc.sysinit.d, so the only symlinks we have to create are ~ the ones to run setclock when the system shuts down: ~ ~ # ln -s ../init.d/setclock /etc/rc.d/rc0.d/K45setclock ~ # ln -s ../init.d/setclock /etc/rc.d/rc6.d/K45setclock ~ ~ At this point, the boot scripts are correctly set up and the only thing ~ that's left to configure is the TZ environment variable. However, I do not find /etc/rc.d/rc.sysinit.d. I do find /etc/rc.d/rcsysinit.d, but there is no link to setclock. What is the value/run level for start? Apparently this script was in LFS at some time, I wonder what happened. The script is no longer symlinked in /etc/rc.d/rcsysinit.d/. It is now ran by udevd. There are two rules in /etc/udev/rules.d/55-lfs.rules that run the setclock script during the time of 'udevadm settle'. SUBSYSTEM==rtc, ACTION==add, MODE=0644, RUN+=/etc/init.d/setclock start and KERNEL==rtc, ACTION==add, MODE=0644, RUN+=/etc/init.d/setclock start Nothing is ever displayed on the screen as this script is run by udevd, which has its own display level, not by init, but be assured that if the /dev/rtc file exists, be it a symlink to a device node, or a device node itself, the setclock script has already been run (unless the setclock script is missing or not executable) during the time of the udev script's run in rcsysinit.d. This does not mean that you cannot create the symlinks in RL0 and RL6 to run the script at shutdown. Hope that helps rather than confuses. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: 2.6.39 - mount /dev/fd0 no longer works
On 06/03/2011 09:28 PM, al...@verizon.net wrote: Thank you very much for the total silence you met this thread with. It warms the cockles of my heart to see there are still people of character around in this wild and crazy world of ours. On a related note, it is actually nice to see that someone still cares enough to take the time to write a sarcastic message with some flavor in this day and age! :-) It sure beats the old Thanks for nothing, grumble and leave routine. Due to your choice of writing style, I was unable to tell whether your sarcasm in the above quoted text was directed *at* lfs-support, or simply posted for the enjoyment of the readers. If not, you should understand that this is a volunteer community and that the reasons for silence are many, the most likely being that very few people use floppy drives any longer, making this community, at least, *unable* to assist. Fortunately, there are people upstream working on the kernel that do still use floppies and it was fixed. If your message was not directed *at* this list, only posted for entertainment, please ignore my comment above and know that I did enjoy reading your response right up until I read that last paragraph. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Kernel panic - not syncing: Attempted to kill the idle task
On 05/10/2011 03:39 AM, shubham jain wrote: When I boot from my LFS CD I get the message: *Kernel panic - not syncing: Attempted to kill the idle task* I am using *LFS live CD -x86-6.3-r2160-min* I have windows 7 also installed on my system. My system details are: * Processor: Intel core 2 Quad 2.83 GHz RAM : 2GB* Being on a 64bit processor, you should probably use the x86_64 Live CD. You can probably get the 32bit CD to work using non-smp kernel with noacpi or other options, but the resultant LFS build will be 32bit as well. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Error compiling Expect 5.45
On 05/02/2011 10:54 AM, Graham Beck wrote: ... and I've just found the 'rm -f libexpect5.45.so' line above that DJ Lucas mentioned was needed. So here's the necessary output: rm -f libexpect5.45.so i686-lfs-linux-gnu-gcc -B/tools/lib/ -shared -pipe -O2 snip Sorry no response until now, I had hoped that somebody else had answered as I have been away for a bit. Anyway, the build is still using the cross compiler. After gcc pass 2 in chapter 5, I believe that the compiler command used should be simply gcc as opposed to the host specific compiler ($LFS-TGT-gcc). Your specs adjustment seems to be correct, but the output of '$LFS_TGT-gcc -dumpspecs | grep ld-linux' posted to list can verify that for you (the path should be /tools/lib/ld-linux*). Chances are that you need to go back and rebuild gcc-pass2. My best guess is that the startfiles fix patch was not applied, however, that does not explain why libutil was not found suggesting that the glibc installation is not good. What is the output of 'ls -l /tools/lib/libutil.so.1'? Given that you are only a few packages in, it might be easier (though less is learned) to simply wipe the tools directory and start over. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Error compiling Expect 5.45
On 05/01/2011 09:14 PM, Graham Beck wrote: /mnt/lfs/sources/expect5.45/libexpect5.45.so: undefined reference to `openpty@GLIBC_2.0' collect2: ld returned 1 exit status make: *** [expect] Error 1 Unfortunately, you've given just enough information for someone to determine that the linker exited with a generic error, and that it is fussing about libutil. The line immediately above the three you've sent, begins with 'gcc' (it should take up about 6 lines on an 80 column terminal), and immediately above that is a line that contains 'rm -f libexpect5.45.so'. You will need to send all 5 of those lines for somebody to make more than a guess about the cause of the issue. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: kernel help please, ACPI Error
On 04/21/2011 02:58 PM, Ken Moffat wrote: Personally, I would be very reluctant to turn off acpi. Let's step back and take another look - in ubuntu, the messages exist in the log and everything seems to work fine, but in LFS they jump up in the terminal and scare you to death ? I've been there in the past for different messages, I can understand how it feels (even editing is a pain when the error messages interfere). I don't know how you have things set at the moment, nor what level of severity these messages are coded at, so the following might not help. But for me it has been useful on occasion - in /etc/rc.d/init.d/sysklogd, change the line which starts klogd to loadproc klogd -c 4 There is also a built in solution without editing the boot script and the value is set in sysinit, prior to running sysklogd: echo kernel.printk = 4 /etc/sysctl.conf I personally use a value of 3, but some people might not like that. I also run sysctl immediately after mountkernfs runs but IIRC, there were some cases where the setting didn't take on really old hardware. -- DJ Lucas -- 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 04/17/2011 03:34 AM, Simon Geard wrote: On Sun, 2011-04-17 at 00:26 -0500, DJ Lucas wrote: Ahh...lightbulb. This is why we currently have the udev-retry in our bootscripts. Are the ids files accessed directly by external programs or by the utility libraries/programs? Provide a common library to access the files (if not done already) and install into the root and place the ids files into the libexecdir, problem solved. I don't pretend to follow the details - I'm going mostly by the statements made by systemd-developer Lennart Poettering on the subject, in response to some of the more recent arguments on the subject: http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken Looking on my own system, examples of offending rules seem to be things like 78-sound-card.rules, which uses the *descriptions* associated with USB device IDs to classify whether a device is a headphone, microphone, speaker, etc. A bit hacky, perhaps (and that file admits as much), but I suppose it's the only way to deal with some hardware. As to why that's an issue at boot time, I *assume* that if the id files aren't present when the hardware is detected on boot, the device won't be correctly recognised. It won't break the boot, but it will cause problems when the user tries using their USB speakers or whatever. Simon. FYI, I'm taking everything said in this thread at face value without really investigating it myself. I've been busy working on the DESTDIR LFS POC. dj [ sources ]$ ls /etc/rcS.d/ S00mountkernfs S03udev S06swap S09localnetS12console S01sysctl S04fuse S07checkfs S10udev_retry S02modules S05setclock S08mountfs S11cleanfs My setup above should be consistent with that of LFS's /etc/rc.d/rcsysinit,d. BTW, just noticed that the fuse devs got FHS broken too, that is their script, not mine. Anyway, udev starts 4th in the startup scripts, it runs across a uevent that uses a rule found in /usr, and it fails to create the device node. The boot process continues, and the rest of the filesystems are mounted, udev-retry replays all of the failed uevents for a second time once all of the required files/programs are in place and the devices are detected and setup as if it were the first time around. Once all uevents are handled, udevadm exits, and the boot process continues. With settle gone, there is no way to *wait* for all uevents to be processed. I would guess that 1 second wait would be way more time than necessary to wait for modern hardware, but how long do we spin for i486? Separate, but local /usr works as expected, now we are still broken WRT to a remote /usr. dj [ sources ]$ ls /etc/rc3.d/ S00sysklogd S02netfs S04haldaemon S06sshd S08samba S01network S03dbus S05cups S07avahi S09gpm In this case, /usr would not be available until 5 scripts later. What happens to those failed uevents? I don't know the answer to that, I would imagine that 'udevadm trigger' could be used again but I don't know for certain. Keep in mind that those devices would never work when booted to runlevel 2, but runlevel 2 is a broken config anyway if you have /usr remote. The upstream devs are certainly correct in saying that no /usr makes all of these problems go away, but I imagine these problems don't exist for the majority of users anyway. At any rate, I'd suggest that we make continue to make provisions for FHS for as long as we possibly can, and still remain compatible with major distros; or until a new major spec comes along that gives us a clear definition. -- DJ Lucas -- 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 04/17/2011 01:31 PM, DJ Lucas wrote: Anyway, udev starts 4th in the startup scripts, it runs across a uevent that uses a rule found in /usr, and it fails to create the device node. Errit creates the device node, but fails to run whatever program in /usr that is required to make it work with the system correctly. -- DJ Lucas -- 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 04/13/2011 09:04 PM, Mike McCarty wrote: There is an incompatibility with using udev and /usr being a separate file system, which users of LFS need to be aware of. It is presently not possible, in general, to use udev and have /usr be a separately mounted file system. This is something to consider when planning the layout of the disc drives. The current implementation of udev is incompatible with the File System Hierarchy Standard. This is incorrect. udev is perfectly FHS compliant as installed in LFS and provides only minimal challenges to make it so in BLFS. dj [ glibc-build ]$ ldd /lib/udev/* 2/dev/null | grep usr libusb-0.1.so.4 = /usr/lib/libusb-0.1.so.4 (0x7f1f8534a000) libusb-1.0.so.0 = /usr/lib/libusb-1.0.so.0 (0x7f1f849af000) libusb-0.1.so.4 = /usr/lib/libusb-0.1.so.4 (0x7f37725be000) libusb-1.0.so.0 = /usr/lib/libusb-1.0.so.0 (0x7f3771e2b000) libglib-2.0.so.0 = /usr/lib/libglib-2.0.so.0 (0x7fcb0a3ce000) libdevmapper.so.1.02 = /usr/lib/libdevmapper.so.1.02 (0x7fbc22d53000) libglib-2.0.so.0 = /usr/lib/libglib-2.0.so.0 (0x7fbc22a6c000) libglib-2.0.so.0 = /usr/lib/libglib-2.0.so.0 (0x7f5455587000) libparted.so.0 = /usr/lib/libparted.so.0 (0x7f54550fa000) libdevmapper.so.1.02 = /usr/lib/libdevmapper.so.1.02 (0x7f545452d000) libatasmart.so.4 = /usr/lib/libatasmart.so.4 (0x7f4d23ac3000) libglib-2.0.so.0 = /usr/lib/libglib-2.0.so.0 (0x7f2631959000) dj [ glibc-build ]$ All of the above FHS exceptions are from BLFS. It doesn't seem too difficult IMO to move 8 libraries (3 of which are already covered in BLFS)...but that is not the end of the road for FHS compliance. It's not just those five libraries that need to be moved, all of their dependencies do as well (which fortunately are already in /lib in the BLFS case). I'd venture a guess that, at most, 20 libraries for any given distro should be moved. I've been rather strict to the FHS for a long time, and while I agree that it is beginning to show its age, the comments about not wanting to support a remote /usr are easily moved to the trash can in my mailbox without any need for entertaining cheese, whine, or lazy developers. Sorry if you feel that is harsh, but it is my honest opinion on the situation. -- DJ Lucas -- 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 04/14/2011 02:55 AM, Simon Geard wrote: Yes, there's been a bit of discussion of this among the distributions of late. Here's a couple of the links I've read on the subject... http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken http://lists.debian.org/debian-devel/2009/05/msg00075.html http://lists.debian.org/debian-devel/2011/01/msg00152.html Wow! Talk about not seeing the trees for the forest! Allow me to summarize: The tool we use to manage our system wasn't designed correctly, so we're going to redesign the system to accommodate our tool. Yep, perfect logic there. I sincerely hope that the comments against remote /usr were not made by anyone with authority as to the direction of Debian. That's not to say that progress need be hindered by backwards compatibility, but for very little gain and some potential loss, the argument was doomed from the start IMO. While not universal, there seems to be a growing feeling that having a separate /usr partition serves no useful purpose these days. The third of those links gives a pretty good summary of that viewpoint. As to compatibility with the FHS, distros seem inclined to ignore the spec, on the basis that it's not being updated, and no longer reflects reality (e.g no mention of /sys). Another discussion on that subject: http://lists.debian.org/debian-devel/2009/02/msg00395.html Same tired arguments. See my earlier post in this thread regarding udev specifically to see how it has been blown out of proportion. -- DJ Lucas -- 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 04/16/2011 05:04 PM, Bruce Dubbs wrote: DJ Lucas wrote: On 04/14/2011 02:55 AM, Simon Geard wrote: Yes, there's been a bit of discussion of this among the distributions of late. Here's a couple of the links I've read on the subject... http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken http://lists.debian.org/debian-devel/2009/05/msg00075.html This is an interesting comment: If we stop supporting /usr on a separate partition, it entirely removes the need for /usr. http://lists.debian.org/debian-devel/2011/01/msg00152.html Wow! Talk about not seeing the trees for the forest! Allow me to summarize: The tool we use to manage our system wasn't designed correctly, so we're going to redesign the system to accommodate our tool. Better quoting needed in my original reply. That response was referring to only the second thread. I'm not sure I see your logic there. For LFS/BLFS having a separate NFS mounted /usr is not a huge problem. For some applications though, the problem of doing that seems to spread across the NFS server and clients. If an update to an application requires a change to the configuration on /etc, then all clients need to be updated anyway. The same issue arises if an application needs to update a kernel module in /lib. Disk space is not really a problem and the ability to push updates across multiple systems exists. Elimination of support for a separate /usr seems to me to have benefits and relatively few drawbacks. It *is* a major change, and many people resist change, but sometimes it's necessary to allow further progress. I should clarify, and probably even retract a bit (though you did snip my comment about backwards compatibility hindering progress). I'm not strictly against getting rid of /usr, and my previous message probably would be interpreted that way, I'm only against many of the arguments behind it brought up in the second thread, for which I was rather heated, specifically about dpkg. I had barely glossed over the third thread when I had written my reply. Yes, it would simplify the layout a lot and add the requirement of an initrd for anything unusual. Now, having said that, *if* the maintenance burden is minimal, removing legacy code to 'force' the use of the newer layout is a bad idea IMO, but I don't know why they are intending to remove --settle switch in udevadm. Is it possible to simply restart/reload udev to replay the failed uevents? -- DJ Lucas -- 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 04/16/2011 08:55 PM, Simon Geard wrote: On Sat, 2011-04-16 at 13:29 -0500, DJ Lucas wrote: On 04/13/2011 09:04 PM, Mike McCarty wrote: There is an incompatibility with using udev and /usr being a separate file system, which users of LFS need to be aware of. It is presently not possible, in general, to use udev and have /usr be a separately mounted file system. This is something to consider when planning the layout of the disc drives. The current implementation of udev is incompatible with the File System Hierarchy Standard. This is incorrect. udev is perfectly FHS compliant as installed in LFS and provides only minimal challenges to make it so in BLFS. dj [ glibc-build ]$ ldd /lib/udev/* 2/dev/null | grep usr libusb-0.1.so.4 = /usr/lib/libusb-0.1.so.4 (0x7f1f8534a000) libusb-1.0.so.0 = /usr/lib/libusb-1.0.so.0 (0x7f1f849af000) libusb-0.1.so.4 = /usr/lib/libusb-0.1.so.4 (0x7f37725be000) libusb-1.0.so.0 = /usr/lib/libusb-1.0.so.0 (0x7f3771e2b000) libglib-2.0.so.0 = /usr/lib/libglib-2.0.so.0 (0x7fcb0a3ce000) libdevmapper.so.1.02 = /usr/lib/libdevmapper.so.1.02 (0x7fbc22d53000) libglib-2.0.so.0 = /usr/lib/libglib-2.0.so.0 (0x7fbc22a6c000) libglib-2.0.so.0 = /usr/lib/libglib-2.0.so.0 (0x7f5455587000) libparted.so.0 = /usr/lib/libparted.so.0 (0x7f54550fa000) libdevmapper.so.1.02 = /usr/lib/libdevmapper.so.1.02 (0x7f545452d000) libatasmart.so.4 = /usr/lib/libatasmart.so.4 (0x7f4d23ac3000) libglib-2.0.so.0 = /usr/lib/libglib-2.0.so.0 (0x7f2631959000) dj [ glibc-build ]$ 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... Simonl Ahh...lightbulb. This is why we currently have the udev-retry in our bootscripts. Are the ids files accessed directly by external programs or by the utility libraries/programs? Provide a common library to access the files (if not done already) and install into the root and place the ids files into the libexecdir, problem solved. The no /usr I've eased my stance on a bit after some sleep and addressed after Bruce's comments. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: \s in sed?
On 03/07/2011 09:13 AM, Tadeus (Eus) Prastowo wrote: Hi! I am in 6.33. Perl-5.12.3 when I read the following sed command: sed -i -e s|BUILD_ZLIB\s*= True|BUILD_ZLIB = False| Although I see that \s means space character, I cannot find \s documented in the info file. Quick googling also does not return a good result about \s. Where do you guys find that \s other than in the source code? Thanks. Google for regular expressions or more commonly referred to as regex syntax. Here is a whole site dedicated to it that I just found: http://www.regular-expressions.info/ http://www.regular-expressions.info/reference.html contains your \s description explicitly. http://www.regular-expressions.info/tutorial.html contains a tutorial...it's geared towards windows I think, but good enough. Be aware that there are differences in regex implementations as well and only some are pointed out in a quick perusal of the tutorial. Also of use (regarding sed at least) is this site: http://sed.sourceforge.net/grabbag/tutorials/ I've used quite a few of the one liners over the past 10 years or so. :) HTH -- DJ Lucas -- 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 02/25/2011 04:38 PM, Bruce Dubbs wrote: Neal Murphy wrote: On Friday 25 February 2011 15:02:23 Bruce Dubbs wrote: It looks like the process is: 1. Use null and console at the start. 2. Mount a tmpfs on /dev hiding the original null and console devices. 3. Create all new devices, including null, on the tmpfs via udev and the boot script. Newer versions of udev or the kernel may make some of these procedures unnecessary, but they don't hurt anything. A device node takes up 1 directory entry and no additional space. I don't understand what appears to be a sense of urgency in your post. What are the drawbacks of the procedure as is? You are quite right. Your three steps work fine and hurt nothing. The drawback is slightly elevated code complexity in building and preparing the system, booting it, as well as the effort to keep and maintain that code. Enabling CONFIG_DEVTMPFS_MOUNT in the kernel (2.6.32+, I believe) reduces the steps to: 1. Mount devtmpfs on /dev; the kernel populates it with devices it knows 2. Run udev to 'take over' those nodes and populate it with everything else Interesting. I hadn't noticed these changes. I had seen the extra configuration item, but didn't put two and two together and simply ignored it as unnecessary baggage (fortunately it actually is with our current boot scripts). Guess I'm getting a little slow. I still haven't looked at it yet, just working from Neal's comments. I don't understand your comment about effort to keep and maintain the code. There were a couple of minor text changes about 7 months ago and prior to that, basically no changes for four years. The comment was only to say that it is now unnecessary. The biggest problem I see for your methodology is that it requires a specific kernel configuration. We don't do that anywhere in the book. We do mention some optional configurations in Chapter 8. Actually, we do. The kernel must be built with tmpfs support as required by udev. Why not extend that and require that devtmpfs support be built-in as well? Assuming it works, and I've no reason to doubt that it does (only that I haven't tested myself), we remove a few lines from the udev script, the mountkernfs script gets a change, a new recommendation is added to the book where the current one is, and a small section of the book is rendered unnecessary - yes the information gets locked away in a little black box, but IMO, that happened 5 years ago when the makedev script went away. The concept of device nodes (and even the devices.txt included with the kernel) is probably already lost to the younger users until it becomes necessary to create one that udev knows nothing about (and those are few and far between). Nothing really lost here, and a small gain in efficiency. The old race car bit fits nicely here: don't look for 1 place to loose 100 pounds; look for 100 places to loose 1 pound. :-) -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Luit questions (Xorg-7.6)
On 01/28/2011 01:09 PM, al...@verizon.net wrote: BLFS Development svn-20110124 * January 23rd, 2011 + [dj] - Removed luit from the book as it is now installed as part of Xorg Applications. Hello, luit-1.1.0 is in the Xorg-7.6 wget list (no surprize here). 1. luit is not in the applications Installed Programs list Sorry for the late reply. I don't frequent LFS-Support (This belongs on BLFS-Support or even BLFS-Dev). Anyway, thanks for the catch. Will be fixed momentarily. 2. For applications, the standard compile command is given as ./configure $XORG_CONFIG In the old days (say, Xorg-7.5) luit would be compiled with ./configure $XORG_CONFIG \ --with-localealiasfile=$XORG_PREFIX/share/X11/locale/locale.alias The default is correct now. What gives? PS - while here, I've noticed Util's are built before Proto's. Any reason? The m4 files are needed prior to using automagic on the proto packages. Since this will rarely be needed, in fact I cannot recall a time that it ever has, I've reverted the change which actually broke the book. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: OpenOffice 3.2.1 on x86_64
On 11/26/2010 05:16 PM, Andre Keller wrote: Am 26.11.2010 03:19, schrieb Stuart Stegall: I was able to make libreoffice-3.2.99.3 build on current SVN x86. A pity you did not mention that before :-)) I wasn't aware of the project and its story... So I gave it a try: SNIP Build was successful but did application did not start (it was complaining about shared library libdb-4.7.so ) SNIP Now everything runs smoothly (well at least the stuff I was able to test so far!) Thank you for the hint I'd try and use --with-system-db in the OOo build. That's why I want the BLFS profile upstreamed so that all of those options are set in stone. IIRC, there used to be an optional configure switch...something to the effect of --extra or similar that passes extra arguments to OOo's configure script (nice if not using a build profile, but patches would still be a nightmare as we don't necessarily want all of the patches). Don't know if that is still there or not. Haven't checked out Libre since Go-oo was rolled into it. It may not be necessary to maintain a particular patchset any longer. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: OpenOffice 3.2.1 on x86_64
On 11/25/2010 08:19 PM, Stuart Stegall wrote: Unsubscribe: See the above information page I was able to make libreoffice-3.2.99.3 build on current SVN x86. BLFS will be moving to LibreOffice in the near future. Hopefully 3.3 comes out soon, if not we'll have to use the 3.2.1 build from before the Go-OO merge. I already have a BLFS profile made-up for go-oo-3.2.1.4. If the BLFS profile proves well in broader testing, I'll try and have it maintained upstream for LibreOffice-3.3.1. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: LFS 6.4 now boots
Nicolas FRANCOIS wrote: Le Sun, 31 May 2009 20:43:34 -0400 Jaiyson SNIP a écrit : SNIP I think the best thing to do for me now is point srikanth tiyyagura SNIP to your thread ! \bye Nico, just a heads up about netequitte. This is for everyone else's benefit as well, and this really isn't a huge deal now days, but when posting replies to a public list, you should try to avoid posting the original sender's address in the body of the message. And you should never post anyone's email address without permission, and *never* on a publicly available mailing list! Posting somebody's email address in plain text on the web makes it extremely easy for spammers to harvest addresses. I think the LFS list software is configured to obfuscate addresses automatically for the archives, by replacing the string '@' with the string '_at_' but not everyone does this with their list setup, nor is this terribly effective now days. For people who do not host their own mail, this really is not a huge deal, but for those who do, it can be troublesome. Just to give you an idea, I have really tight spam filtering on my server. I'd imagine that there are at least a few false positives every week, so some mail I'm just not getting, but the trouble of making filtering light without the letting in too much spam is not worth the couple of FPs every week. I usually receive about 3-4 spam messages every week. Grepping my mail logs, on my address alone, I've stopped 2763 messages at the door and another 422 had to be processed by Spam Assassin over the past 7 days...and SA is a big memory resource. Simple actions, like not posting a raw email address to an online forum, helps all mail admins and users alike, to reduce the amount of junk that they have to deal with. Please keep this in mind in the future. Thanks in advance. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Scripting some LFS steps?
Justin Yaple wrote: I had to lookup what top posting was actually. So I am I still doing this incorrectly sorry its still new to me. Perfect! After the script fails I have been able to restore my enviroment to the point of the previous sucess, and complete this step manually. Here is a copy of the script I run for GCC Pass 2. Its pretty much line by line from the 6.4 book. Running these commands manually has worked so I find it odd that from a script they have been failing. snip partial script that looks like correct commands No shebang? No comments? How is this script executed? One wrapper script around a bunch of mini scripts, or run manually? Or are these commands part of one big script? If so, break it apart. Also, again, how is it logged? `script.sh 21 | tee -a compile.log` or something similar? I honestly have no idea why it doesn't work correctly. The commands appear to be correct. I'm assuming that you've only shown the commands for brevity. In the future, showing the full output of `cat script.sh` (or whatever name you've given the script) would be more desirable, as that would avoid any questions about completeness, and get the obvious questions out of the way. [...@name25 ~]# cat blahblahblah.sh #!/bin/bash # Begin ~/blahblahblah.sh echo blah blah blah # End ~/blahblahblah.sh [...@name25 ~]# ls -l blahblahblah.sh -rwxr-xr-x 1 dj dj 85 2009-04-14 22:09 blahblahblah.sh [...@name25 ~]# Again, HTH. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Scripting some LFS steps?
Justin Yaple wrote: I appologize if this should have been in lfs-support. I thought here might be more appropriate as its about automating LFS. Please do not top post, and do try to trim your responses to keep only the necessary part of the previous message. This ensures that the conversation flows easily from message to message without having to read the entire thread. There are 3 helpful links in the FAQ if this style of email communication is new to you. http://www.linuxfromscratch.org/faq/#netiquette Also, please send future responses to lfs-support@linuxfromscratch.org as previously requested. This thread has been moved. Yes, I just read the FAQ on this topic, it could use some rewording as it is not very clear, but the ALFS list is for ALFS development, not for support requests. I can manually run the commands fine its just when I execute them from a sh script the process fails with Out of memory:. snip I have 1GB memory + 1GB swap space This _should_ be plenty sufficient. and again manually running the command works fine. That doesn't _seem_ very likely, and still hasn't been qualified yet (see next para). You also haven't provided all of the needed information. What is the host environment? What version of LFS are you building? Are you running X? Does it work correctly when run manually on the same PC? Do you have sufficient disk space? Etc. Running the check target again simply picks up where it left off when it last failed. Did you actually verify that a gcc build and test runs from start to finish by restarting the GCC build from clean source (ie: remove gcc-4.x.x and gcc-build directories) in a similar environment on the same PC? The easiest way to troubleshoot this problem, is to run top from another term while running your script. Unfortunately, you'll have to monitor it until the failure occurs. Sort the list by memory used, and just before the error occurs, it should be readily apparent where the memory is being wasted. Also, just another quick idea, it may prove useless, but how are you logging the output, is it from each individual script's output to a log file, or the whole ball of wax from the top level script? Please let us know what you find. And if top doesn't pan out, or if you need further assistance, please continue in this thread, the list volume is minimal (or post via gmane if you do not wish to subscribe). HTH -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready polluting my login prompt.
Charles Turner wrote: 'man sysctl' should point you in the right direction, but the quick answer is: echo kernel.printk=3 /etc/sysctl.conf This makes the kernel output messages pertaining to errors only as I understand it (which does what i want, but i bet there is a better way to do it, I'm reading through my drivers documentation atm) Correct. Warnings will still show in log files, just not on console (the first value). It is, IMO, not necessary to show warnings which are non-fatal to end users. However, that specific message is incorrect in the driver and should be changed. Unfortunately, it's been that way for a long time. I'd be surprised if nobody has complained about it. It should be an info message at best, maybe even qualifies as a notice, but certainly should not be a warning. man 2 syslog details the different log levels. I don't get warnings from my NIC driver (e1000 btw) anymore, but I think this means I don't get any warnings now. root:/# cat /proc/sys/kernel/printk 4 4 1 7 Hmm, the setting did not 'stay' for whatever reason. I have put kernel.printk=3 in my /etc/sysctl.conf file, but this psuedo file doesn't seem to show the change which I find odd. And if the printk() function takes these four arguments, what does kernel.printk=3 do? Set them all to 3? Only the first value (console log level) is set if only one is provided. To set more (or all) values, enclose the space delimited values in quotes. ex: `sysctl -w kernel.printk=4 4 1 7` I no longer have the problem, so thank you DJ Lucas. But after reading the manual pages and the linux-2.6.27.4/Documentation/sysct/kernel.txt file, I'm left with more questions :( Thank you for your time. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready polluting my login prompt.
Charles Turner wrote: About 2 seconds after the /etc/rc.d/init.d/network bootscript has finished the login prompt appears and then a second later the message [ 9.783223] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready is displayed over the login prompt. Pressing enter gives you the login prompt again, but it's annoying. The network bootscript has not been modified in any way here. So I'm guessing this happens to everyone who is using stock LFS bootscripts. I could see anything on the mailing lists. Nope, this is probably specific to your NIC (or rather its driver). Question: How can I catch this message and suppress it properly? 'man sysctl' should point you in the right direction, but the quick answer is: echo kernel.printk=3 /etc/sysctl.conf HTH -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: A Suggestion For A Simple Package Manager
Frank Peters wrote: Yes, that is correct. The install commands are specified in the Makefiles for a package. If it would be possible to redirect output from these commands to a text file, that certainly would be a lot simpler than the approach taken by package managers such as installwatch or CheckInstall, which use libraries to intercept certain kernel system calls. Well then the author needs to manually add those commands to the auto tool scripts. Got a standard in mind? For working with existing scripts, you could do something similar to the following and achieve your goal: mv /usr/bin/install /usr/bin/install.orig cat /usr/bin/install EOF #!/bin/bash # Begin install wrapper /usr/bin/install.orig $@ $HOME/install.log # End install wrapper EOF chmod 755 /usr/bin/install Unfortunately, you'd need to do the same with cp, ln, mkdir, mknod, mv, rename, rm, etc. Suddenly, the approach by installwatch, CheckInstall, and other like approaches, makes quite a bit more sense. Additionally, there is a reason that the vast majority of makefiles today support DESTDIR. The following is what I (and others) have proposed several times for the book. We simply install to the DESTDIR for all packages, and then manually install the package from the DESTDIR. If you want to tar up the DESTDIR for binary packages, then go for it. The install commands that you'll need to give to your favorite PM's install and post-install scripts are provided (complete) by the book's instructions at that point. In this manor, we've managed to explain the complexities of PM, give real examples, and still avoid using any particular PM by default. Dependencies are already covered by the book, the only thing left is upgrading. Concerning upgrades, Perl (specifically perldoc) is the only catalog type file that I didn't cover in my suggested instructions (posted a couple of months ago) that would be of even remote interest in LFS. A couple of others have already taken this approach as well and might even already have that one covered, I haven't taken the time to look at others' docs/scripts yet. Now BLFS is tens of times more interesting (read complicated), but it could get there with a little effort. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Q: why are the auto-tools in LFS and not BLFS?
Jeremy Henty wrote: I'd always taken it for granted that m4, autoconf, automake etc. had to be in LFS, but recently I thought Hang on! The auto-tools are *development* tools, not build tools. Building auto-tooled software only requires a shell, make, sed etc. You don't need autoconf and friends unless you want to develop software.. So, since creating an LFS system only requires building existing software, why does it include the auto-tools? Could we not move them to BLFS? What am I missing here? Regards, Jeremy Henty Define development. We patch the source, so IMO we are doing 'development' to some extent. If you make changes in the build (by modifying auto-tools scripts), then the auto-tools are required to regenerate the configure script and makefiles. Although I don't believe that there are any such changes in current LFS, there have been many in the past. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: GCC DESTDIR
Jack Stone wrote: Agathoklis D. Hatzimanikas wrote: I've never tried to use DESTDIR in LFS. Diy Linux is using this technique for years by the way. You might want to look on the reference build: http://www.diy-linux.org/ Thanks for the reminder. I had a quick look and Greg doesn't seem to be doing any steps after installing the chroot phase gcc so I might not have problems. By the way it would be interesting to see the final results, if you attempt to use DESTDIR in chapter06. In fact, I thought it was a target for LFS-7.0. I was planning to put notes on -dev once I've got something working. FYI, I have done this for 6.4 and posted my scripts in my home dir. They do work and can certainly save you some time. http://www.linuxfromscratch.org/~dj/packages-6.4.tar.bz2 Be sure to extract from within an empty directory as I didn't create one in the tarball. I also did not see a reason to use DESTDIR for chapter05, so I did not do so. Finally, holding the testsuite run until after the target installation will reduce quite a bit of cruft in those scripts. If you only like to review the scripts, then they are already extracted here: http://www.linuxfromscratch.org/~dj/DESTDIR-LFS-6.4/ -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: cannot open root device hda3
Ken Moffat wrote: Google has various reports that gcc-4.3 couldn't build 2.6.24, with similar errors. If Ralph is trying to get back to a working hda device, I think he needs to try the version you mentioned (2.6.27.something). So, take the default config from 2.6.22.5 and save it as ~/config-2.6.22.5. Then blow away the 2.6.22.5 directory and extract the 2.6.27.something sources. Then cp ~/config-2.6.22.5 .config and then makeoldconfig. IIRC 2.6.27.5 made libata 'stable'. I hope I have the version correct, but that was why I suggested 2.6.27.4 as was in the book. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: cannot open root device hda3
Ralph Porter wrote: Yep. booting from 6.3 livecd export LFS=/mnt/lfs chroot $LFS /usr/bin/env -i HOME=/root TERM=$TERM PS1='\u:\w\$ ' PATH=/bin:/usr/bin:/sbin:/usr/sbin /bin/bash --login root:/sources/linux-2.6.22.5# make mrproper make LANG=en_US.iso88591 LC_ALL= menuconfig save file with no changes (defaults worked last time) make kernel/built-in.o: In function `getnstimeofday': (.text+0x196b9): undefined reference to `__umoddi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x19774): undefined reference to `__udivdi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x19797): undefined reference to `__umoddi3' kernel/built-in.o: In function `update_wall_time': (.text+0x19ee9): undefined reference to `__udivdi3' kernel/built-in.o: In function `update_wall_time': (.text+0x19f13): undefined reference to `__umoddi3' make: *** [.tmp_vmlinux1] Error 1 Everything looks correct there. Strange. I honestly don't recall exactly why (technically), but I've seen that before. I think it was a simple environment error (PATH was set but not exported in my case I think it was...maybe, not sure). Can't hurt to try exporting PATH from inside the chroot environment, and running ldconfig again, and then review what is in /etc/profile, ~/.bash_profile, and ~/.bashrc for errors. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: cannot open root device hda3
Ralph Porter wrote: I have an hunch that if you go back to 2.6.27.4, disable experimental drivers, and rebuild, this will probably disappear, the suspect being libata. -- DJ Lucas thank DJ, thats what I was thinking also since I did not have to configure anything to compile the kernel. NOW I get. kernel/built-in.o: In function `getnstimeofday': (.text+0x196b9): undefined reference to `__umoddi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x19774): undefined reference to `__udivdi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x19797): undefined reference to `__umoddi3' kernel/built-in.o: In function `update_wall_time': (.text+0x19ee9): undefined reference to `__udivdi3' kernel/built-in.o: In function `update_wall_time': (.text+0x19f13): undefined reference to `__umoddi3' make: *** [.tmp_vmlinux1] Error 1 make mrproper first? -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: cannot open root device hda3
Ralph Porter wrote: Hello folks. I'm working lfs book 6.4 (have already done 6.3) and am tying first time boot. error: VFS: cannont open root device hda3 or unknow block (2,0) please append a correct root boot option: here are the available partions kernel panic - not syncing: VFS unable to mount root fs on unkonw block (2,0) OK I have an hunch that if you go back to 2.6.27.4, disable experimental drivers, and rebuild, this will probably disappear, the suspect being libata. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: lfs 6.4 - 6.9. Glibc test errors
Hassan Zamani wrote: Hello I'm in section 6.9 of lfs 6.4, I have made glibc and in the test section I got the flowing errors from grep Error glibc-check-log: make[2]: [/sources/glibc-build/posix/annexc.out] Error 1 (ignored) make[2]: *** [/sources/glibc-build/rt/tst-cpuclock2.out] Error 1 make[1]: *** [rt/tests] Error 2 make: *** [check] Error 2 are these harmless messages or not, if not what I must do next? annexc is normal, just ignore it (the test has been actually been fixed once or twice over the past several years but really, it has been broken forever). I'm not sure what tst-cpuclock2 is. What is the host system's kernel version and additions? Try running the test manually and Google for the results (or post here), see if that sheds some light. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: jhalfs issue with permissions
Ralph Porter wrote: Building target 028-binutils-pass1 [/du: cannot read directory `/mnt/lfs/.Trash-root': Permission denied 0 sec du: cannot read directory `/mnt/lfs/.Trash-rporter': Permission denied Wait, it actually started the build! I missed that part yesterday. What exactly is the problem? The du commands? The build shouldn't stop because of that, did it stop, or did you stop it? Anyway, the du errors are harmless, but the reason is that the lfs user (just created) does not have read access to those directories. As for the 'Sorry, try again' errors...What happens if you do 'sudo useradd lfs'? Assuming those were errors and not that I just misinterpreted the problem, is SE enabled? I haven't heard of SE causing problems yet, but I'd disable or at least set to permissive. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: jhalfs issue with permissions
Ralph Porter wrote: mk_LUSER You are going to log into the user account lfs sudo requires a password Password: Sorry, try again. Since you didn't explicitly say it, we'll go for the obvious first. Did you add rporter to /etc/sudoers and give him all commands? RedHat AS/EL used to have good comments in the /etc/sudoers file. I don't know about Fedora, but the needed change is available on the BLFS sudo page: http://www.linuxfromscratch.org/blfs/view/svn/postlfs/sudo.html -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LFS 6.3 chp 6.12.1
Stealth wrote: The book says to run this grep -o '/usr/lib.*/crt[1in].*succeeded' dummy.log and get this /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../crt1.o succeeded /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../crti.o succeeded /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../crtn.o succeeded but I got this /usr/lib/crt1.o succeeded /usr/lib/crti.o succeeded /usr/lib/crtn.o succeeded I followed the book exactly, so where did I make a mistake, or is this ok? Could this be a result of what I asked about in my other post that no one answered? Nobody had a definitive answer for your other post. I haven't seen the extra errors. As far as the /usr/lib/crt?.o above...it is actually the correct explicit path, but I've ever only seen it relative to /usr/lib/gcc/machine/version/. What changes, if any, have you made in your build? Also, what is the host system? Maybe that'll give somebody's memory a little jog. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: On Dec 14 (4 days ago) I ask for help! Message still not posted WHY?
Ray Hogaboom wrote: Hi I am new to Linux From Scratch This is the 1st time I have tried any thing this advance with Linux. Every thing up to this point ch 6.9 has worked fairly well. The only problems I have had is some confusion with the instruction. Where I have not been in the right directory when entering a command or as in this chapter. I entered this sed -i '/vi_VN.TCVN/d' localedata/SUPPORTED because it was the 1st userinput box on the page. It failed then I noticed you need to First apply two patches that are in the 2nd userinput box on the page. After applying two patches then sed -i '/vi_VN.TCVN/d' localedata/SUPPORTED I worked my way down the page to where instruction said: Should have worked either way. Again, add the needed compiler flag to CFLAGS: echo CFLAGS += -march=i486 -mtune=native configparms I changed this to echo CFLAGS += -march=i686 -mtune=native configparms I would like to keep this setting as I have no computers less than a i686 If you did not do this in chapter 5 as well, then the readjusting the tool chain section will fail. Build glibc again. Farther down the page I copy userinput box cp -v ../glibc-2.8-20080929/iconvdata/gconv-modules iconvdata make -k check 21 | tee glibc-check-log grep Error glibc-check-log Then I pasted that into the shell The errors I am getting are below root:/sources/glibc-build# make -k check 21 | tee glibc-check-log (I cut out most of history here) make[1]: Target `check' not remade because of errors. make[1]: Leaving directory `/sources/glibc-2.8-20080929' make: *** [check] Error 2 root:/sources/glibc-build# grep Error glibc-check-log make[2]: [/sources/glibc-build/posix/annexc.out] Error 1 (ignored) make[2]: *** [/sources/glibc-build/rt/tst-cpuclock1.out] Error 1 make[2]: *** [/sources/glibc-build/rt/tst-cpuclock2.out] Error 1 make[2]: *** [/sources/glibc-build/rt/tst-cputimer1.out] Error 1 make[2]: *** [/sources/glibc-build/rt/tst-cputimer2.out] Error 1 make[1]: *** [rt/tests] Error 2 make: *** [check] Error 2 root:/sources/glibc-build# I know that make[2]: [/sources/glibc-build/posix/annexc.out] Error 1 (ignored) is normal. I have saved shell history back to 6.2. Preparing Virtual Kernel File Systems if needed. I'm not sure about the other errors. Really, you should do as the book has instructed you to do before asking for help. My system processor model name: Intel Celeron CPU 1.80 GHz or = to pentium4 Thanks for any help Ray Hogaboom -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: glibc problems
Frank Peters wrote: If anyone is interested, I can make a tarball of the modified UCBTEST code that compiles and runs well on my machine (an x86_64) and upload this tarball to my personal web page. It would just need to be untarred and executed. Frank Peters Sure, however a patch to the original would be better. First, the changes are more transparent for it's users, and less bandwidth used by the person hosting it (you). And you could probably even post it on list. Besides that, it could also be placed in LFS patches. Personal web sites tend to change rather frequently. From personal experience, 4 years down the road, you won't want to receive messages about it missing. :-) -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Compile error Lfs-6.4 glibc-2.8-2008929
Dr. Edgar Alwers wrote:
Trying to compile glibc-2.8-20080929 according to the new
Lfs-6.4 book, I get already problems with the pass 1 compilation. The last
part of the messages ( after some minutes of compilation ) are
quote
/mnt/lfs/sources/glibc-2.8-20080929/posix/../nptl/sysdeps/unix/sysv/linux/i386/../fork.c:76:
snip
Unfortunately, the above errors do not make for a very useful problem
report. If William's suggestion is not the correct one, we'll need to
see the error that is causing the side effects that you've posted...IOW,
the very first error, all the text back to, and including, the compiler
command. Usually, the first error is the only real error, the rest are
just side effects, so please keep that in mind for any future support
requests. Also, if you can't scroll that far up, then you'll need to
pipe to a file: Instead of something like 'make {target}', use
'make {target} 21 | tee ../glibc-compile.log'
HTH
-- DJ Lucas
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Mailing lists archives
William Harrington wrote: So anyone gonna fix the archives? None of the archives can be downloaded. No archive from any mailing list can be downloaded. Forwarded to lfs-dev so that at least some of the proper people see it. I don't recall the admins group address right off the top of my head. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: A Suggestion For A Simple Package Manager
Gordon Schumacher wrote: DJ Lucas wrote: No. I suggest we fix this once and for all and use unionfs No I didn't! ;-) -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: A Suggestion For A Simple Package Manager
Esben Stien wrote: Unionfs only helps with collecting the written files done by any install script, but it does not solve package management; like inserting, removing, listing, locating, etc, so I also need a solution there. Pretty much the same methods used in any package manager, only the path to get there is longer by mounting a union, installing package, unmounting a union, mounting it elsewhere. Using DESTDIR is at least two steps less. Installation is easier and likely RPM spec files (or other PM support files) already exist to cover most if not all of this work. Here is a very brief rundown of the typical process...hope I didn't skip a step. Options B and C are not appropriate for a binary distro. Corrections are welcome from those who use typical binary packaging. Option A. 1. configure package, build package, install into alternate prefix (DESTDIR, or union if you prefer). 2. review makefiles to see what was done for post installation steps such as updating indexes, linker cache, info dir index, gconf schemas, .desktop files, etc. though most of that comes by looking at the installed files after you've done it for a while. Put all this into a script to run as a post installation script (take into account all possible times that this package could be installed and account for everything so that not human intervention is required) 3. remove any files that should be updated and not overwritten. 4. separate package into bin, bin-$qual, dev, doc, doc-$sub, lib, lib-$sub, lib-$sub-$qual, and lib-$qual packages and archive as appropriate. 5. separate post-install script created in step 2 for each of the above sections. 6. review ldd output for library dependencies of installed files to make a dependency tree. 7. review post installation steps for dependency information 8. Install all files until they can be removed (when everything else is installed and dev files and no longer needed). 9. Run the full post-install script created in step 2. Option B 1. use somebody else's spec file or PM support file. 2. Modify for your site 3. verify via steps 1-9 in Option A above are accounted for (they usually are) (skip steps 2 and 3 if the file was generated for the package you are installing by an LFS contributor and you trust that contributor). Option C I still choose yet another custom method that makes more sense to me in a build from source environment (only used for restore purposes if I should break something since I'll never install a binary package completely). 1. Log the entire installation including a header with build commands 2. Log the installed files (either by timestamp, DESTDIR, or union) 3. make a list of updated files from previous logs (next time around use this list of updated files to archive the updated files as step 3). 4. Tar up everything that is installed except the typical updates to files that are dynamic (see step 2 in Option A above if unsure). HTH -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Question on 6.60 (Stripping Again)
Scott wrote: Wow, I can't believe I've made it this far without disaster! Just a question here: The book (6.4-rc1) warns to ensure that none of the programs to be stripped are running, and suggests re-chrooting if unsure whether chroot was properly entered. However, I recall that in the bash chapter we were specifically told to fire up the newly-minted bash, so it is running! Shouldn't this say to absolutely re-chroot? Anyway, that's what I did. Hmm...strange. I have no idea. Have to look back into history a bit. Second question: Now that I am almost there, was it stupid of a newbie to do this with an rc? What perils lurk for me and will I be doing this whole thing over again soon? Well..you'll probably be treading water for a bit. BLFS is nowhere near ready for LFS-6.4, though we are getting there. Create a Track account and follow along with the bugs there, and be very conscious of any configure output for missing deps. That said, your build should be LFS-6.4 Final minus a couple of locales for test suite coverage IIRC. Good luck, and congrats! -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LFS 6.3 chpt 5.7 step cmd problem
Stealth wrote: I am following the book as it is written. The only exception was I used kernel 2.6.27.7 . This is not good, though not likely the cause of the problem you are seeing. You should be using 2.6.22.19. The latest 2.6.22.x should be safe as far as kernel headers and udev are concerned. I forget what the kernel requirement for the next problematic udev was (dont' even remember what udev version it was), but it would *probably* be safe up until that version. Fuzzy 2.6.25.4 comes to mind for some reason, but if you don't need features from that version to be known in glibc (you likely do not), then use the 2.6.22.19 version to build the system. You can upgrade the kernel after the fact. I am either reading the book incorrectly or I am finding flaws in the flow of the material in the book. I am not saying the people writting the book don't know what they are doing. I am saying the people writting the book probably know this stuff so well they accidentally leave stuff out or get things out of sync just enough to cause problems for people like me who are depending on the book to guide me. No. I never meant to imply that there was _missing _information, 'out of sync' information, or missing instructions. All the needed information _is_ there, like the example you showed the other day, some of it could probably be presented better to assist people who are unfamiliar with the build process. If there were any missing information, devs would be having a heck of a time, as even automated, we build by extracting the book's commands verbatim. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LiveCD LFS book 6.3 chapter 5 questions
Stealth wrote: I have read the book from start to chapter 5.3.1 about 6 or 7 times trying to figure out what I missed. I don't see anything unless 5.1 and 5.2 actually have steps that I am supposed to do. 5.3 When I do this in chapter 5.3.1 mkdir -v ../binutils-build cd ../binutils-build I get this error: mkdir: cannot create directory '../binutils-build': Permission denied First and foremost; Welcome to LFS! But, you missed a step. See: http://www.linuxfromscratch.org/lfs/view/6.4/chapter05/generalinstructions.html The second important box tells you to extract the tarball and enter the newly created directory before executing any of the book commands. Good luck and most importantly, as frustrating as it can be getting started, have fun. It's all worth it when you see it boot *your* LFS the first time. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LiveCD LFS book 6.3 chapter 5 questions
Stealth wrote: It sure would help if this chapter was made a lot more clear by adding some more information. At some point in the future after I know what I am doing with building my own OS from the book I will be glad to help make the confusing steps easier to see and understand. Absolutely. Though I'm not so sure about _more_ information. AFAICT, all of what was discussed is there, albeit poorly ordered as the answer to the two questions you asked, which are directly related, happen to be two chapters apart (3.1, 3rd paragraph; and 5.1, 2nd 'Important' box). After several years of building LFS, this stuff is kind of second nature...the finer details can easily get lost without a new set of eyes on it. When you get your head wrapped around it and get a few packages in, if you would like to suggest updated text, we would very much appreciate it. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Question @ 10,000 feet
Alexander Haley wrote: Basically, the fundamental thing that bugs me is ... I type 'make install' and scads of files arrive on the file system ... and I really don't quite know their role, purpose or importance ... Do I really need to know the purpose of each and every library file that is installed? Probably not .. but, I am irked that I'm typing 'make install' and just crossing my fingers that the system is getting it right (of course the system often gets it right .. but does it teach me? no. or at least, not yet.) This is different than the original question. For this particular part, at least IMO, it's easier to look at it backwards. Take a log of installed files, and look at them. Some names will be self explanatory, while other will have absolutely nothing to do with their functions, or rather too simplified to deduce what its function is. From there, you have a makefile to look at to see how that file was assembled, and then the source code of the individual parts that went together to make that file. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Question @ 10,000 feet
Alan Lord wrote: Alexander Haley wrote: snip / Basically, the fundamental thing that bugs me is ... I type 'make install' and scads of files arrive on the file system ... and I really don't quite know their role, purpose or importance ... Do I really need to know the purpose of each and every library file that is installed? Probably not .. but, I am irked that I'm typing 'make install' and just crossing my fingers that the system is getting it right (of course the system often gets it right .. but does it teach me? no. or at least, not yet.) Here's a way (hopefully) to help you understand what is being installed at least. Use the DESTDIR* prefix with make install: http://www.gnu.org/prep/standards/html_node/DESTDIR.html So you can create a ~/tmp/packages area or some such, and install the package into there first. You can then see which files are really installed (for many, I think you'll find a lot are text files, e.g. docs, man pages, config files etc...). Another really useful tool for viewing all this stuff is the tree command which can display the contents of your installed package in a nice, well, tree fashion ;-) Finding the source for tree can be tricky but a few pages down in Google I came across this link: ftp://mama.indstate.edu/linux/tree/ for it. (Of course you could try installing it with the DESTDIR variable and check what it does before installing properly. * I gather that DESTDIR is not supported by *all* packages but by most. (An alternative is to do a build changing the --prefix=/path switch on your first configure run. But then you will need to rebuild again when you are happy. The advantage of DESTDIR is it doesn't require you to change the --prefix switch. The disadvantage is that if you move from the DESTDIR, you have to be aware of things like the info dir, gconf updates, .desktop or icon additions, etc. Pretty much any update to an existing file will have to recreated manually. In the end, this is probably much better for learning exactly what is going on, and this is also how the big distros do it. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Question @ 10,000 feet
Alan Lord wrote: Oh I see. I never intended my post to suggest subsequent copying of files that way. Sorry if I badly worded the OP. The way I have used it [DESTDIR] is purely to allow easy inspection of the files the install process creates. If I am happy with what it does, then I simply go back to the package's build directory and run make install without the DESTDIR variable... That is an effective use of DESTDIR. However, what I was getting at is that most distros use DESTDIR for packaging. Any updates are done as part of a group of post-install tasks, which will force you to look at the makefile to see what was supposed to have been done. This really isn't the case after you've done it a few times, most of the time you can look at the DESTDIR and see what needs to be done, but until you learn to recognize the obvious items, this practice will force you to learn how the makefiles work too, and so, DESTDIR is a very good suggestion for exercise. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Question @ 10,000 feet
Simon Geard wrote: On Wed, 2008-11-19 at 09:24 +, Alan Lord wrote: That's interesting. Do you mean that DESTDIR actually affects the contents of some files when you run make DESTDIR=/my_path install? I always assumed, perhaps wrongly, that it merely changed the destination path for the root of the install process, but kept in tact the paths of --prefix and other switches that were applied during the configure. Yes, it does merely change the destination path. But doing so might be the difference between creating a new file, and adding to an existing one. No specific example comes to mind, /usr/share/info/dir is most common, until you get past X, and get into gconf, desktop file utils, etc. But yes, make install *can* and does modify existing files. Simply copying from the DESTDIR to the final destination will result in a broken system (though it's probably not that difficult to recover if you keep good backups or logs). but suppose two packages append entries to a file /etc/whatever. Installed normally, you'll have one file with two entries. Installed with separate DESTDIRs, you'll have two different files at DESTDIR1/etc/whatever and DESTDIR2/etc/whatever. Simon. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Can't compile xorg-server. Posted here pending fixing my access to BLFS
Ralph Porter wrote: On Nov 13, 2008, at 6:45 PM, Dan Nicholson wrote: I recompiled as described below but still got the same error. Looking at xorg-lib-compile.log there is mkdir : cannont create directory '/usr/local/include/X11/Xtrans': permission denied. Judging from the above, XORG_PREFIX was not set, which probably means that XORG_CONFIG was not set. You will need to start over from the beginning on the installation of Xorg, and be sure that you export the variables after you set them (or at the same time). However... Even if i log on as root it still denies X11 is drwxr-xr-x ...I have no idea why you cannot create a directory as root. That is really messed up. Sorry. Hopefully somebody else has an idea. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: xorg build
Ralph Porter wrote: whoops, sorry, wrong list...moving to blfs... On Nov 8, 2008, at 11:31 PM, Ralph Porter wrote: I must be missing something here. The instructions in blfs for xorg 7.2 says to run the script. bash -e #exit on all errors snip Well, when I run this i get. grep: ../proto-7.2.wget: No such file or directory. No URLs found in -. Never seen your message show up on blfs-support, but the wget file should be placed in the suggested xc directory and you should be working from there, however, the wiki links contain instructions specific to each section including the one off seds and patches for each group. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: xorg build
DJ Lucas wrote: There is a link a little further up the page in the 'Additional Files' section. Err...'Additional Downloads' as Trent already mentioned. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: xorg build
Ken Moffat wrote: But, it's all about what works for you - ISTR Randy uses some package management system which identified files being overwritten by something else in the base LFS system, which I certainly hadn't known about. I assume from your comments above that you use something akin to install-log. If so, this is a very simple addition. Before moving your installed files log to the final destination, grep -R across the destination directory for each file in the temporary log file, append something useful, say \(M\) for modified, to the line if you find it already installed. :-) When I get around to finishing my packaging scripts... -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: xorg build
Ralph Porter wrote: I just finished LFS, so, now what next? I think I want KDE and firefox next. But what should really come next? I'm using this as learning tool, so working in command mode seems to lengthen that process. On the subject of package managers. Do I want to go there now, later or what? What comes next depends on your requirements. You'll have to pick a path and follow the dependencies. Tough advice I know, but that is the way the distros have to do it too. I take it this is your first build. I generally pick logical stop points, and make those the individual goals. Personally, I start with a text based browser (links) and GPM (console mouse software) so that you can copy and paste commands (add a dhcp client if you cannot configure a static IP). Next is X, then the Firefox stack, then all of Gnome...etc. As far as a PM, FBBG (Folow Book, Book Good) is an old term around here, but definitely has it merits. You definitely do not want a package manager yet as it makes things insanely more difficult. After you get a good feel for BLFS, although technically too late, you can then introduce a PM (so that you know where to look, and more importantly, how to troubleshoot _when_ it fouls up). LFS-7.0 will add some bits for PM from the get go, however, the recommendation I think, will still be to build without a PM for the first time. Good luck and have fun. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: xorg build
Ken Moffat wrote: On Sun, Nov 09, 2008 at 05:09:06PM -0600, DJ Lucas wrote: I assume from your comments above that you use something akin to install-log. I don't think I do - for system builds I just touch a file, do the install, then find what is newer than the file (I don't ever automate uninstalling, so when files like /etc/ntp.drift show up, I don't really care. Yes you do actually. This is almost exactly what old install-log does, though it excludes directories in the find command so that you don't have the other problem. I'm not sure if newer variants do the same however. :-) -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: xorg build
Ralph Porter wrote: Thanks guys... I found the proto-7.2.wget file by poking around. There is no additional files on this screen. Maybe my browser is having issues? http://www.linuxfromscratch.org/blfs/view/stable/x/xorg7.html On a mac with firefox. Oops, now I see where you are. The script you are referencing is only an example. Each section (proto, libs, utils, fonts, drivers) has it's own instructions to download all of the packages using the wget files, however, the section page only provides generic instructions to install each of the 200+ packages one by one (as many people use package management). On each sectional page, there is a wiki link that contains the commands necessary to build the entire section with a for in do loop. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: I DID IT...
GMail wrote: Finally... This monster that has been eating my time and patience is up. IPL'd my version of LFS at 20:00...woohoo. Congrats! -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: ifconfig
Ralph Porter wrote: Was ifconfig suppose to be installed someplace? If so in what step as I do not have it on my new system. No, LFS uses IPRoute2 by default. It is a much better tool, however you can add net-tools from BLFS if you absolutely cannot bring yourself to use /sbin/ip for everything. Take a look at the ipv4 script in /etc/sysconfig/network-devices/services directory for the common use examples. Or see net-tools (which is where ifconfig comes from): http://www.linuxfromscratch.org/blfs/view/svn/basicnet/net-tools.html -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: locales issues
Juan A. Moreno wrote: I have found a solution. At the end of the console boot script the dead keys are disabled due a kernel bug. At least in the previous version of lfs-bootscrips. I dont have tried the current version 20081023. Sorry for the late response. Yes. The kernel now contains the mentioned patch (or similar). BROKEN_COMPOSE was removed from lfs-bootscripts only a few days ago. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: kernel configuration and installation
Richard Melville wrote: Yes, I think you've missed the important thing ;) The kernel headers are what glibc was compiled against, and they should not be changed unless you upgrade glibc [ and before anyone misconstrues that, we *don't* support upgrading glibc - when the time comes, build a new system ]. Hi Ken My reading of Rob's post was that he was wondering why distros like Ubuntu could frequently update kernel headers when we are told not to. If this was not his question then I wouldn't mind some advise on this issue. The problem occurs when some packages insist on parsing /usr/include/linux. I had a problem recently when installing VLC. I had enabled DCCP in my new kernel and I wanted to build VLC with the required support. I had already tested DCCP and it was working OK, but the VLC build failed complaining about missing headers. When I checked the source code it was looking in /usr/include/linux, which surely must be bad practice. No. Not bad practice, that is why we 'sanitize' the kernel headers for use in userspace. VLC, however, should be looking for its own copy of the kernel headers if it requires a particular version (see below). I can't see why arbitrary packages should be poking around in the kernel headers. Clearly, as my glibc was built against much older kernel headers its search was unsuccessful. I was wondering what the solution is here? Should we install the new kernel headers into a separate sub-directory and change the source code to point to the new sub-directory rather than to /usr/include/linux, or would this just not work? According to the kernel devs, or at least last time I _heard_ (hearsay) anything about the subject, the answer was that the VLC maintainers failed to include the necessary kernel headers in the distribution tarball and provide a runtime check of the kernel for the necessary feature(s). I'm not certain if this is still current practice, and would appreciate a confirmation on that. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Another try at GAIM on pure 64
Arnie Stender wrote: Hi, A while back I tried to compile gaim-1.5.0 and was having some problems. With a suggestion from Ken I got it to compile but the way I remember it I started getting weird errors that had to do with changing my theme. Even the gaim list couldn't help me so I dropped it for some time. The other problems I was having with themes seem to have been resolved so I figured I would go back and try again to get gaim running. I was able to get it compiled and installed (the check seemed to work although I never really saw anything that said one way or another that things were good or bad) but when I run it the window comes up but when I try to IM someone gaim exits with a message that it couldn't create mcop directory. strace puts it like this: write(2, can\'t create mcop directory\n, 28can't create mcop directory Can someone give me a clue as to what mcop is and how to fix the problem? Even strace doesn't tell me where it is trying to create this directory. I also saw a number of references to .kde in the output of strace. I'm running gnome. Any help will be greatly appreciated. Thanks, Arnie Gaim is compiled against QT/KDE. IIRC, either run it once in KDE, or do this: mkdir ~/.kde/socket-name1/ Might be a little more to it, but it's something along those lines. HTH -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Truecrypt
Has anyone used the program called truecrypt? http://www.truecrypt.org I am writing a wrapper script for mount (/sbin/mount.tcfs) that checks the user's homedir for a password file and will eventually pass it to truecrypt so that the standard mount command can be used without user interaction. Mounting actually works as expected (though not all the options are accounted for and I still have to enter a password...adding next). However, what I'd like to have happen is on umount, that the device map for the tc file is cleared so I'll have to execute a coommand after the umount happens. Now my real question: Just using umount with no switches, how do I, or is it even possible to, execute a command after the device is unmounted?--without writing another wrapper script for umount, I already thought of that but I'd like to send the script to the developer when It works as I want it to. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: eth0 not detected
randhir phagura wrote: # ip addr show 1. Intel: BPOADCST, MULTICAST mtu 1500 qdisc noop qlen 1000 link/ether 00:02:a5:a4:3f:bf brd ff:ff:ff:ff:ff:ff Snip Does this indicate something to you? Well, yeah. Unless I'm reading that incorrectly, it appears that the device normaly refered to as 'eth0' is now 'Intel'. Does this ring any bells as to how it was changed? Though I haven't bothered with persistent naming rules, I'd guess this will work: = /etc/rc.d/init.d/network stop #This will probably error on you mv /etc/sysconfig/network-devices/ifconfig.eth0 \ /etc/sysconfig/network-devices/ifconfig.Intel /etc/rc.d/init.d/network start == -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: eth0 not detected
randhir phagura wrote: No the kernel does detect but does not bring-up eth0. The dmesg gives the following, as related to eth0: eth0: OEM i82557/i82558 10/100 Ethernet, 00:02:A5:A4:3F:BF, IRQ 11. Receiver lock-up bug exists -- enabling work-around. Board assembly 729857-001, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0x04f4518b). Receiver lock-up workaround activated. e100: Intel(R) PRO/100 Network Driver, 3.4.14-k2-NAPI e100: Copyright(c) 1999-2005 Intel Corporation The dmesg is similar to my older LFS booted with kernel-2.6.14. Does ip or kernel give any other output? Try this once the system is up: ip link set eth0 up # or down echo $? Maybe do a 'dmesg -n 7' before hand to see all the kernel messages on the console. The output should be the same, but maybe not...we'll see. If that fails, as I expect it should, try 'ip addr show' and see if eth0 is in the list at all, but I can't see why it would be. I'm just grasping for straws in hopes that something obvious will show up to help you. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Fresh OOo-2.0 install cannot save documents or add printer
Alonso Graterol wrote: I just finished building OOo-2.0.2 from source according to http://www.linuxfromscratch.org/blfs/view/svn/xsoft/openoffice.html adapted for 2.0.2 version. I've used OOo-1.1.4 in Slackware before so first thing I tried was to set up a printer. To my surprise spadmin did not allow me to install anything. The generic printer did not show up either. Looking at the share/psprint folder I noticed there was no driver subfolder so I copied from the 1.1.4 install to 2.0.2 the driver subfolder plus GENERIC.PS file. Now I can select a printer and modify some settings but once I'm done with spadmin printer and settings dissapear. By default, OOo2.0.2 will not install printer PPDs if cups is installed. You can find the printer ppds in /usr/share/cups/model/ to add your printer. whatever OOo application I want to print with complains there is no default printer defined. Going back to spadmin confirms such reality. Where does OOo saves printer selection and settings? I do not know where, but I'd expect it to be in ~/.openoffice.org2. Check the perms on this directory, your new ppds, and maybe cups ppds? Kinda grabbing at straws on this one. Besides that, any application would not let me save any document (writer, calc, impress, etc) for the first time (Save as functionality). Dialog shows up but there is only a screen blink when clicking save button and filename dissapears and dialog remain open but that's it. Saving an existent document is flawlessly though. Any ideas? None ATM. I do not see this issue. What version of LFS, or better what glibc, gcc, jdk, and wether using native file picker? Which patches were used and where did they come from? -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Sparc boot image with ssh?
Hi all. I have just found a sparc box that I'd like to play with. I have no idea what it's capable of doing, but I need a way to boot it. Currently it has no HDD (so no OS). I also do not have keyboard, mouse, monitor for sparc, and no pci slots in it so no VGA. :-) Since I literally paid for the box with pocket change, I really don't wish to purchase these peripherals for it if not required, but I will if absolutely needs be to boot it. Anybody know where I could find a bootable CD image with dhcp and ssh? BTW, the box is dual UltraII 300s with 1GB of RAM. May not be capable of much, or may be ok...I really don't know much about them. TIA. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: is LFS LSB compliant?
Ken Moffat wrote: On Thu, 6 Oct 2005, Chakkaradeep C C wrote: hi all, i just want to know whether LFS is LSB or FHS compliant? snip LSB - no. The LSB is for providers of binary software, among other things it mandates RPM as a package manager, and a particular version of the c++ libraries. No doubt you can build the necessary packages, and the specific version of gcc, to achieve compliance with a particular version of the LSB, but most people don't think that is worthwhile. You might want to read Ulrich Drepper's recent blog on the LSB: http://www.livejournal.com/users/udrepper/8511.html Ken Just FYI, I am currently working on a LFS set of LSB compliant bootscripts...and the needed install_initd script (who's functions are stored in a separate file for other init types to take advantage of). I'm working from what Nathan and Alexander had already done in the bootscript CVS. Mostly just because I like to see nice looking bootscripts as it's the first thing the user sees when booting the PC, but having consistancy here is a good thing for everyone who uses a sysv style boot (including Jim's parallel boot scripts) IMO. Unfortunately, I've not had a chance to really look at runit yet (yes I had intended to try it well over a year ago) so I don't know if it can take advantage or not. But this is all on hold for the moment in prep for OOo-2.0...but I'd be happy to put up some samples of what I have done so far if anyone is interested. It's really made the LFS scripts nice and easy to read. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: rc scripts not running...
[EMAIL PROTECTED] wrote: hey all... i think ive narrowed the problem down... i have successfully built a LFS 6.1 system... it boots, and i get a sh-3.00: prompt here's the thing, i dont think it is running the rc scripts... the root filesystem is mounted read-only, i have no networking, etc. once I cd into the /etc/rc.d/rcsysinit.d/ dir and run each script, the system runs fine what do I need to do so the system runs the rc scripts? Under normal circumstances? Nothing. ;-) Do you have appended to your kernel line in grub.conf init=/bin/sh ? Something is telling it to use /bin/sh. Maybe that'll help, maybe not. If not, please post /etc/inittab, and ls -l /etc/rc.d/init.d/ and /etc/sysconfig/ . -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Boot to Linux to load Windows
K. Mike Bradley wrote: I run several training centers and each has 12 PC's which need to be reloaded after each class. Since the last round of Security patches, the MS DOS NET Client 3.0 will no longer work and I am dead in the water and at my whit's end. Can anyone steer me in the right direction? Yes, LFS-Chat. This is major OT for this list, but I'll answer anyway and direct you towards lfs-chat for any further questions. Have you looked at the corporate version of Symantec Ghost, or the Altiris Deployment Suite? Use an OEM preload for servers, else just sysprep the image PC for workstations. Further discussion to lfs-chat@linuxfromscratch.org please. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
OT Re: X libraries or include files not found - gtk+-1.2.10
Randy McMurchy wrote: Please folks, trim the original stuff from the messages before you reply. It is a PIA to have to scroll down hundreds of lines to read one line of original message. OT: I know it doesn't fix the problem, but it does help a bit when you are absolutely sick of telling people to trim their replies. :-) Give the extension QuoteCollapse a try. http://quotecollapse.mozdev.org/ -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: A Hotplug question
Gerard Beekmans wrote: Nothing is actually locked, the kernel just printed a message to your screen. You can change this using the dmesg command. The '-n' option changes the level at which kernel logs are sent to the console. I'm not sure which level you would need to set to prevent these USB messages from appearing. You would have to experiment with it. If you set the level to '1' (dmesg -n 1), the console will receive no messages except kernel panic messages. All messages, including the ones that aren't printed, still go to the system log daemon as usual. A perfect place to show off a recent addition to the LFS-Bootscripts. They now contain the sysctl script which allows you to set /proc/sys params at boot time (where this value is stored). In this case, we want to change the values in the file /proc/sys/kernel/printk. Try this: echo kernel.printk=3 /etc/sysctl.conf Obviously change the 3 to your log level preference. Probably more explanation than is needed, but that particular file is a bad example because there is more than one value. If you should need to change more than the first, they are space delimited; the values have to be quoted. IOW: (echo kernel.printk='3 4 1 7' /etc/sysctl.conf) -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Firefox and profile locking: Chapter 2
Andrew Benton wrote: I've done a bit more testing with this. Making a packaged build with the firefox-1.0.4 source results in a firefox that will (if you already have it open) open a new url in the current window without launching the profile manager. It doesn't open a new window or tab though so you lose the page you were looking at. If I make install with a firefox-1.0.4 build it runs but when I try to launch a second instance (e.g. from a link in an email) I get the dreaded profile manager. So make install is definitely broken on the 1.0.4 branch. However, if I do make install from a current trunk build it works perfectly. It opens a second instance in a new tab or window, just like it should. I had a look around http://bugzilla.mozilla.org/ earlier and couldn't see a bug that matched. I wondered about filing a new bug but couldn't be bothered. The Andrew, thank you very much for taking the time to dig in on this problem. Firefox 1.0.4 branch was cut from the trunk just after firefox-0.8, it's really old code. The current trunk works, why file a bug against an old branch? Agreed. I don't know a bit about FF's release schedule, but if it apears to be fixed in trunk, then I'd think it useless to dig all the way to the bottom of it, short of a personal goal. BLFS can change it's build process to the known working one assuming we can control the interface using -remote. Do you know if adding '/usr/bin/firefox %s,new-tab' to your WM's default browser line will force opening in a new tab as opposed to in the existing window? The other desired behavior would be 'firefox %s,new-window'. We may have to add the '-remote' prior to '%s' or possibly muck with the '' (double quote) chars to make it work as expected...easy way to troubleshoot is to make it open in a term so that you can see the error messages. It may well have to be something long like this: '/usr/bin/firefox -remote openurl(%s), new-tab'. Another obsticle, in a default build BLFS style, is that FF refuses to open if '-remote' is passed and there is no existing processs, the very reason I doctored up that shell script I had found (changes only for url protocol guessing, and window controll, which could be made into a switch to make it easier to change between new-tab new-window). I really wish I knew where I had found the original. If this does not work and can't be beaten into submission by the WM, I'll say that both methods are broken to some extent and suggest that we continue with the existing instructions and add a furthur modified shell script. I'm now building firefox with your recomended build method as I type this, but won't be able to return to it for another 18 hours or so. It also seems funny that trunk build opens in a tab or window...perhaps they changed the remote shell script a bit. IMO, a new window should be the default action as dictated by history, but it should be controlable by the local user's firefox registry, or better, from the options dialog box in the UI. Anyway, on with the testing. :-) Thanks again. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: LFS in a USB flash drive/memory stick
Roberto Perpuly wrote: Hi all, Has anyone put their LFS in a USB flash drive/memory stick? I am trying to do so but I am stuck in one place. Here's what I have done. 1.) Wiped out all partitions on my USB drive and made 1 FAT partition using the command Snip umhum. default linux prompt 1 timeout 600 display boot.msg label linux kernel vmlinuz root=/dev/sdb1 init=/sbin/init 6.) Restarted my machine, and the USB boot seems to do fine. The kernel is unpacked and finds all sorts of devices on my computer. However, I get the following error: Cannot find init. Try Passing an init= option to the kernel. Any ideas on how to troubleshoot? RP I can only use the swag method here, but I'd be willing to bet the problem lies in your choice of root filesystem. The kernel is looking for /sbin/init, not /SBIN/INIT or /Sbin/Init. This is only a guess, I don't really know. I don't have a vfat to test with right now, but you might want to mount it again from the host and take a look at the directory structure. IIRC, case is not preserved if filenames have less than 8 characters, but I could be wrong completely. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: how to check the failed boot message
Chakkaradeep C C wrote:
hi,
just check out at what initscripts file u r getting error and just use
echo command in the initscripts file and sleep 3 to make it sleep
3 secondsand in this way u can find where actually the error
is..hope it helped u out
This is a very good suggestion, to assist a bit more, just put a 'echo
$0 sleep 3' just before the end of the boot_mesg() function in the
/etc/rc.d/init.d/functions script. $0 is the name of the current
process (running script). It'll be really ugly output for the ones that
work, but it'll help you find the error. For a reference point, the end
of the function should look like this:
--
# if CUR_LENGTH was set to zero, then end the line
if [ ${CUR_LENGTH} == 0 ]; then
echo
fi
echo $0
sleep 3
}
--
-- DJ Lucas
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: udev rule questions
Jeremy Utley wrote: DJ Lucas wrote: Okay, I need a bit of udev help. I want to write a rule to create a dvd synlink. I've always done the dvd symlink like this: KERNEL=hdc, NAME=hdc, SYMLINK=dvd. That should definately do it for you, always has for me. -J- Yes, should work nicely, except it's system dependent...I want a generic set of rules so that I can dump it into an ALFS profile and just have it work on whichever pc I choose to build on today. :-) The cdsymlinks script is very close to what I wanted...with a little tweak, a little later on, it should work for everything. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: udev rule questions (udev dvd dvdrw cdrom cdrw)
DJ Lucas wrote:
Jim Gifford wrote:
DJ, in udev there is a program called cdsymlinks, that can do this
already. BLFS is going to need a udev section to add this in from the
udev-xxx/extras directory along with it's configuration file.
That's perfect! Thanks!
Well, almost. I'd think there needs to be an extra check
for the dvd device by default, IOW: if there is both a dvd writer and a
cdwriter, then the cdrom link should go to the cdrw device in most
cases. The reason being, why would you keep that old cdrw device around
if it didn't do something that the dvd doesn't..say like read subcodes
for CD+G which so far has been impossible on all recent drives with the
exception being Plextor CDRW drives. :-) I'll look at that when more
time is availible.
Anyway, thanks again for the pointer. And just for the archives, but
watch the wraping, udev rules contain long lines...
tar -xf udev-0.54.tar.bz2
cd udev-0.54
mkdir /etc/udev/scripts
cp extras/cdsymlinks.sh /etc/udev/scripts
cp extras/cdsymlinks.conf /etc/udev
chmod 754 /etc/udev/scripts/cdsymlinks.sh
cat /etc/udev/rules.d/20-cdsymlinks.rules EOF
BUS=ide, KERNEL=hd[a-z], PROGRAM=/etc/udev/scripts/cdsymlinks.sh
%k, SYMLINK=%c{1} %c{2} %c{3} %c{4} %c{5} %c{6}
BUS=scsi, KERNEL=sr[0-9]*, PROGRAM=/etc/udev/scripts/cdsymlinks.sh
%k, SYMLINK=%c{1} %c{2} %c{3} %c{4} %c{5} %c{6}
BUS=scsi, KERNEL=scd[0-9]*, PROGRAM=/etc/udev/scripts/cdsymlinks.sh
%k, SYMLINK=%c{1} %c{2} %c{3} %c{4} %c{5} %c{6}
EOF
And don't forget to uncomment the variables and set them appropriatly in
/etc/udev/cdsymlinks.conf.
Optionally you can compile the cdsymlinks program and use that which
also uses the config file, but I'd prefer the flexibility of the script
(which I can probably edit later to give the cdrw the cdrom link if both
cdrw and dvdrw exist).
-- DJ Lucas
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
udev rule questions
Okay, I need a bit of udev help. I want to write a rule to create a dvd synlink. The /proc/ide/hdb/model file contains the string DVD with some other text. I got around that using grep 'DVD' in a PROGRAM field set. This is fine for *my* setup, but I want this thing to be generic for optical devices as I may suggest a modified version for use in BLFS later on if it works out well. So, the first question I have to ask...Is there a better way to determine dvd from cdrom? There has got to be, but it's not readily apearent to me. Next, I want to distinguish writeable from not writeable. Again, I used a PROGRAM field with grep 'write-only' in /proc/ide/%k/settings. There is probably a better way for that too. But the next problem, it doesn't seem that I can combine two PROGRAM fields in the same rule. Right now my second hard drive (hdf) has symlinks for dvd and dvdrw. :-) This means that either the second PROGRAM field took precedence, or my model ID on that HDD contains the string DVD (which it doesn't). Another thing I didn't understand about that is that I would have thought hda would come as the first match, so it is overwriting the link on every pass. Is there a way to avoid this or did I miss something obvious? I'm pretty sure there are better ways to detect both of these variables in sysfs or proc, I just don't know where to look. Here is the failing rule for those interested: # Create the /dev/dvdrw symlink (implies dvd): BUS=ide, KERNEL=*[!0-9], PROGRAM=/bin/grep 'DVD' /proc/ide/%k/model, PROGRAM=/bin/grep 'write-only' /proc/ide/%k/settings, NAME=%k, SYMLINK=dvdrw dvd It is the first uncommented rule in the file and probably matches every ide device in the system assuming it awarded only the second PROGRAM field. TIA. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
