Re: [lfs-dev] popt in the book?
The discussion is about the feasibility of removing perl from *LFS* - all of the packages you listed except GCC are outside of LFS Sent from my iThingy On 6/06/2012, at 8:10, g@free.fr wrote: - Mail original - De: Jeremy Huntwork jhuntw...@lightcubesolutions.com À: LFS Developers Mailinglist lfs-dev@linuxfromscratch.org Envoyé: Mardi 5 Juin 2012 16:09:51 Objet: Re: [lfs-dev] popt in the book? On 6/5/12 2:05 AM, g@free.fr wrote: This make me smile a lot. There is much more dependencies in perl than just glibc and linux packages. Check a bit your log with grep -rl 'perl 'logdirectory Getting perl hits in your logs does not always equate to actual dependency. Configure scripts may check for perl even if it's not required and packages may at times install supplementary perl scripts that aren't typically used at runtime. Few packages actually require perl to be present to build and/or run. JH -- I looked only at the build side with my compilation logs looking for 'perl ' and '\.pl '. Not all my compiled packages are in verbose mode, so I may miss some call and every anonymous perl script that is not using a .pl name. This was observed with the usage I made from those package, often with more --disable options than LFS/BLFS. bind-9.8.3 use a perl script fcron-3.0.6 use a perl script gcc use texi2pod.pl krb-1.9.3 has many perl one-liner call, libpcap-2.22 has one perl one-liner call linux-atm-2.5.2 call a perl script ntp-4.5.3 call a perl script openssl-1.0.1c produce the asm from a perl script and Configure is a perl script openswan-2.6.38 use a perl script syslinux-4.05 need perl to create some code wget-1.13.4 use texi2pod.pl I skipped here all perl related packages Good luck to compile without perl. Gilles -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Adding LVM/RAID/initfamfs
On Wed, Jan 25, 2012 at 4:49 PM, Bryan Kadzban br...@kadzban.is-a-geek.net wrote: Zachary Kotlarek wrote: On Jan 23, 2012, at 7:56 PM, Bryan Kadzban wrote: UGH. FWIW I really don't like this feature. It causes the booted-with-initramfs case to require different handling from the booted-without-initramfs case, once the bootscripts are running, and therefore requires changes to the bootscripts if you use an initramfs. Why? Can't you mount the devtmpfs both with and without the initramfs? Not if it's already mounted, unless you want to undo the modifications that udev has made (by putting a new mount on top), or make changes to the bootscripts (which is exactly what we're trying to avoid with this setup). :-) switch_root does exactly this already NOTE: somewhat untested, based on reading of documentation udev is not run in the initramfs - devtmpfs is used alone. Mounting devtmpfs causes the kernel to popoulate /dev with known devices when mounted. You don't have the complexity available with udev for rules, permissions, naming, firmware loading, etc, but (except for the last case) that's not normally needed for an initramfs to identify the root device. The steps are (pseudocode) mount devtmpfs /dev identify rootdev mount $rootdev /mnt/root mount --rebind /dev /mnt/root/dev (atomic move of dev to real root mount point) exec switch_root $rootdev /mnt/root /sbin/init (atomic move of real root to / and exec /sbin/init as pid 1) No changes should be needed to bootscripts -- -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Adding LVM/RAID/initfamfs
, and execute the real init process.
==
Kernel Compilation (existing section)
==
Enable the following kernel options
General setup ---
[*] Initial RAM filesystem and RAM disk (initramfs/initrd) support
() Initramfs source file(s)
==
Copying Kernel Modules
==
For each kernel module that needs to be in the INITRAMFS, do the following
modinfo /lib/modules/$(uname
-r)/kernel/subsection/module/module.ko | grep depends
e.g. If you root filesystem is EXT4, and you have compiled it as a module, do
modinfo /lib/modules/$(uname -r)/kernel/fs/ext4/ext4.ko | grep depends
The output should be similar to the following, which shows we need
those two modules as well.
depends:mbcache,jbd2
Create the /usr/src/initramfs/lib/modules directory:
mkdir -p /usr/src/initramfs/lib/modules
Use find to search and copy the module and it's dependencies
find /lib/modules/$(uname -r)/ -iname mbcache.ko -exec cp {}
/usr/src/initramfs/lib/modules/ \;
find /lib/modules/$(uname -r)/ -iname jbd2.ko -exec cp {}
/usr/src/initramfs/lib/modules/ \;
find /lib/modules/$(uname -r)/ -iname ext4.ko -exec cp {}
/usr/src/initramfs/lib/modules/ \;
Repeat above for any other modules required.
Build the initramfs cpio archive
cd /usr/src/initramfs
find . -print0 | bin/busybox cpio -ov -H newc | bzip2 -9
/boot/initramfs.cpio.bz2
add following to /boot/grub.cfg after linux line
initrd/boot/initramfs.cpio.bz2
Should make a recommendation to leave initramfs source in place for
future updates\changes, or instructions on how to extract from cpio
archive. Note that changes to INITRAMFS need only to replace cpio file
in
/boot, kernel recompile not needed.
@
FIXME: should note there is an option to build cpio into kernel? may
complicate issue? extraction is painful using kernel image, and
require kernel recompile for any changes
@
--
-- -
Steve Crosby
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Adding LVM/RAID/initfamfs
On Mon, Jan 23, 2012 at 4:33 PM, Steve Crosby steve.cro...@gmail.com wrote:
cutpasto
${INITPRG:=/sbin/init}
should be
: ${INITPRG:=/sbin/init}
--
-- -
Steve Crosby
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Adding LVM/RAID/initfamfs
On Mon, Jan 23, 2012 at 4:57 PM, Bruce Dubbs bruce.du...@gmail.com wrote: Steve Crosby wrote: I've been experimenting with initramfs recently (I used to use initrd for my cdrom bootable lfs firewall). It's relatively straightforward. I understand dracut may automate some of the LVM\MD\RAID stuff (not looked at it yet), but for purely educational purposes, isn't a hand-crafted version better? What you have is interesting, but if you are not using LVM/MD/RAID, what is the purpose of your initramfs? AFAIK, the only real reason to use an initramfs is to mount the root fs and the kernel is quite capable of doing that for plain file systems. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page 1. Education ;) 2. Providing an emergency shell in the event of failure to mount root filesystem -- -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Adding LVM/RAID/initfamfs
On Mon, Jan 23, 2012 at 5:36 PM, Steve Crosby steve.cro...@gmail.com wrote: 1. Education ;) 2. Providing an emergency shell in the event of failure to mount root filesystem 3. (not relevant to LFS) Auto-detecting which device the root is on, when the boot device is portable\non-persistent (usb\cdrom\etc) e.g. my LFS can end up as an iso, and run in a VM, or applied to usb stick, therefore the real root device is variable. -- -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Adding LVM/RAID/initfamfs
On Mon, Jan 23, 2012 at 7:58 PM, Zachary Kotlarek z...@kotlarek.com wrote: On Jan 22, 2012, at 7:33 PM, Steve Crosby wrote: 3. Populate /dev using busybox cutdown version of udev (mdev) Is there a benefit to mdev over just using tmpdevfs? I say that as a current user of mdev; I haven't yet tried a tmpdevfs initramfs device system. But if I'm understanding it correctly tmpdevfs should be sufficient for any use were an default-config mdev run would work, and requires less configuration/tools, less boot scripting, and the need to wait for a coldplug scan in the initramfs. I haven't yet reviewed devtmpfs, so didn't implement it in my initial cut of scripts. From reading, it has several significant advantages, including the ability to move the /dev mount to the new root and thus not miss any events and thus not require udev to replay them in the real bootscripts. It is not however automatically mounted in an initramfs (deliberately), so still needs the mount line, but the kernel hotplug helper and scan can be eliminated. Will add to todo list ;) -- -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Adding LVM/RAID/initfamfs
On Mon, Jan 23, 2012 at 6:05 PM, Bruce Dubbs bruce.du...@gmail.com wrote: Steve Crosby wrote: 2. Providing an emergency shell in the event of failure to mount root filesystem That's reasonable too, however I never recall needing that capability. The times I have had problems have been when grub can't load the kernel and if I can load the kernel I can always edit the command line in grub to use init=/bin/bash. Agreed. Perhaps we should mention that in the grub section of the book as a diagnostic\troubleshooting step. Note however that if your rootfs fails to mount as a result of a fs error, that won't help you ;) Also, the switch in grub config between hd0,1 and /dev/sda1 for a root fs quite often catches people out. Being able to have a diagnostic userspace where they can actually ls /dev and see what their kernel thinks is the disk device, or using lspci et al is helpful. 3. (not relevant to LFS) Auto-detecting which device the root is on, when the boot device is portable\non-persistent (usb\cdrom\etc) e.g. my LFS can end up as an iso, and run in a VM, or applied to usb stick, therefore the real root device is variable. Can't you use 'mount'? I get something like: /dev/sda8 on / type ext3 (rw) Wouldn't that be easier? Nope. If your root device is a USB stick, the /dev mapping changes depending on which USB hub\port you plug into - at kernel root mount time, there is no facility to use any of the udev device\name mapping, so early userspace is a requirement. All live-cd based systems use this approach as well, since they don't know how many cd-rom's you have, the type, or where they are in the device chain. As above, not relevant for LFS though ;) There seems to be a trend in Linux to embrace the complex when simple solutions will suffice for most people. The first exhibit is systemd. systemd is a solution looking for a problem ;) Primarily aimed at people who want fast boot times, the parallelisation is very good, but the dependencies really bite. So far, systemd requires (both directly and indirectly) dbus, gperf, attr, intltool, libcap - and aside from parallel scripts, and some esoteric use cases, provides no advantage I have yet to discover to the masses over sysvinit. -- -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] systemd dependencies data point
just running a quick install of systemd on a livecd host installation to track dependencies\etc in addition to documented requirements in README kernel = 2.6.39 (LFS7 ok) libudev = 172 (LFS7 ok) dbus = 1.4.0 libcap there are at least the following other dependencies intltool (requires perl = 5.8.1) gperf since my quick livecd setup doesn't meet the udev requirements the configure step failed at this point, but at least this is a first data point - will build inside a current LFS installation shortly for a more comprehensive list. also, note that dbus and systemd have circular build dependencies, and the recommended build method is (from the README) dbus (without systemd support) systemd dbus (with systemd support) -- -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Udev-177 Kmod-3 WIP patch
On Tue, Jan 17, 2012 at 9:22 AM, Gilles Espinasse g@free.fr wrote: - Original Message - From: Jeremy Huntwork jhuntw...@lightcubesolutions.com To: LFS Developers Mailinglist lfs-dev@linuxfromscratch.org Sent: Monday, January 16, 2012 6:54 PM Subject: Re: [lfs-dev] Udev-177 Kmod-3 WIP patch On Jan 16, 2012, at 12:27 PM, Bryan Kadzban wrote: I'd be curious what's in /proc/mounts as well, but eh whatever. Is there a reason LFS doesn't just symlink /etc/mtab to /proc/mounts? JH -- In some cases, the symlink case may fail when that work with a real file /etc/mtab. In 2009, coreutils-8.0beta rm/one-file-system test fail with the symlink from /etc/mtab to /proc/mounts http://lists.gnu.org/archive/html/bug-coreutils/2009-10/msg00278.html the example that fail was mount --bind /dev/shm/tmp10767 a/b ... umount /dev/shm/tmp10767 umount: /dev/shm/tmp10767: not mounted I don't know if behavior has changed since 2009 (running kernel was probably 2.6.24 or 2.6.16) I read that Fedora moved the symlink from /proc/self/mount to /etc/mtab, this is required for systemd. Gilles Not *required* but systemd will issue a warning on boot if /etc/mtab is not a symlink to /proc/mounts Then again, systemd will also issue a warning on boot if /usr is a different partition than / *sigh* @ developers who think they should determine user administration policy in code... Hint: because you think this is the way it should be done does not automatically make you right, nor make anyone who does it differently wrong Now I get to write\maintain a patch to silence your silliness in deciding how I should configure my system. -- -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Patch naming
On Thu, Jan 12, 2012 at 3:16 AM, Andrew Benton b3n...@gmail.com wrote: On Mon, 09 Jan 2012 21:23:59 -0600 Bruce Dubbs bruce.du...@gmail.com wrote: Just a reminder that we did at one time adopt a patch naming convention: pkgname dash version dash short underscore descriptive underscore name dash patchrev3.patch That is, the name should be: thunderbird-9.0.1-libpng_1.5-1.patch not thunderbird-9.0.1-libpng-1.5-1.patch I don't agree with this. The patch is to fix thunderbird with libpng-1.5, not libpng_1.5. It's not called libpng_1.5 so why should the patch be called libpng_1.5? Andy thunderbird-9.0.1-fix_for_libpng-1.5-1.patch? -- -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Confused about some E2fsprogs notes
On Thu, Oct 9, 2008 at 5:22 PM, Trent Shea [EMAIL PROTECTED] wrote: On Sunday 05 October 2008 16:43:32 Bruce Dubbs wrote: [EMAIL PROTECTED]: ~/build sudo /sbin/debugfs -R feature /dev/sda3 debugfs 1.41.1 (01-Sep-2008) Filesystem features: has_journal filetype needs_recovery sparse_super large_file it shows only a subset of the features the book says. I don't really know how to determine what to do at this point. I show many less features than the book does. What should I do to ensure the feature list is correct? I'm pretty sure this only lists the actual feature set of the partition, not the list of all possible options. See sudo /sbin/dumpe2fs /dev/sda3 | grep features I've run both commands on a file system and had the same results appear, so I dug around a bit, and it looks like this was discussed a bit back in the day: http://linuxfromscratch.org/pipermail/lfs-dev/2006-July/057711.html The purpose of the test was to check if your *host* system has a modified e2fsprogs, which means that when you create your LFS partition using that modified software you may run into problems when in chroot, as we won't have those same modifications with the LFS installation of e2fsprogs. As long as you don't have *more* that the feature set listed, your okay. This could perhaps indicate the wording of the paragraph could use some adjustment. -- -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GMP and MPFR
DJ Lucas wrote: I do not have all the details in front of me, but somebody said that gcc failed if gmp was not on the host in pass1. Greg pointed us to a DIY thread that showed how to build with GCC. There was no _need_ to build inline beyond that point, because that fixed the problem of the extra host system requirement. The extra packages are minimal, and required one way or the other. Shared seems better IMO as I use GMP anyway. It might not be a bad idea (less maintenance) to build the same way for both early builds and only build gmp and mpfr standalone for the final, though I haven't tried that yet. FYI: The GMP and MPFR packages can be built in Chapter 5 as seperate packages (no need to inline with GCC), but must be built statically (due to linker issues with finding shared libraries outside normal paths) and require configure switches are needed to help MPFR (and possibly gcc) locate the static libs (--with-gmp=/tools from memory) The Chapter 6 chroot shared build works due to the shared libs being in a standard location (/usr/lib, etc), and the linker able to find them using normal paths. So Chapter 5 can be inline with GCC (which builds static by default) or seperate but static, and Chapter 6 can be shared or static as you prefer. -- -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GCC-4.3.1, Linux-2.6.26.2
On Wed, Aug 27, 2008 at 12:22 PM, DJ Lucas [EMAIL PROTECTED] wrote: TheOldFellow wrote: Notes: Chapter 5. 1) GMP and MPFR need to be built before GCC pass1 in Ch5. They are prerequisites of GCC. I built them into my host system, but they could probably go into /tools (before GCC as well as after). Yeah, I wasn't sure what to do about them. I figured since I built them in the host environment, that was fine, but it adds another dependency to the host. I'm pretty sure gmp would be part of the snip FYI: building them in the tools directory is going to be problematic. During the stage 1 build of gcc, the make system is unable to locate the libmpfr.so.1 library, and so aborts. I'm not familiar enough with the convoluted logic of the compiler makefile magic, so not sure of how to add /tools/lib to the compilation - no amount of configure (--with-gmp, --with-mpfr), LDFLAGS (-L/tools/lib) or other magic has so far allowed that path to make it to the stage1 build process from toplevel. It may be necessary to use the older save binutils dir and have a LIB_PATH of /tools/lib and /usr/lib, then clean and remove /usr/lib during the toolchain adjustment steps. (I'll try this method anyway, just to see if it works). I'll experiment some more, but it's likely that unless I get lucky, I'll revert to the known working method of adding the needed libraries to the host toolset. At some point this will need to be addressed, if nothing else for sucessful building from the LFS6.3 LiveCD, which doesn't have these libraries. -- -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GCC-4.3.1, Linux-2.6.26.2
On Wed, Aug 27, 2008 at 8:05 PM, Greg Schafer [EMAIL PROTECTED] wrote: Steve Crosby wrote: FYI: building them in the tools directory is going to be problematic. During the stage 1 build of gcc, the make system is unable to locate the libmpfr.so.1 library, and so aborts. Guys, this issue has already been solved. Just unpack the GMP and MPFR tarballs into the already unpacked GCC tree and *build them as part of the GCC build*. It solves most problems and is clearly the more robust approach. More info here: http://www.diy-linux.org/pipermail/diy-linux-dev/2008-February/001192.html Thanks Greg, appreciate the pointer. Another solution is to modify the gcc build instructions (pass1 at least, will confirm pass 2 later, but ld LIB_PATH change likely means no change needed) as follows. The method below requires only unpacking gmp\mpfr once, but thats a fairly minor point. More importantly, we can include a note about use of LD_LIBRARY_PATH\ld.so.conf when referencing libs installed in non-standard directories, which increases educational value - the editors can decide as they wish ;) 1. Move gmp\mpfr instructions to before gcc pass 1 2. Add --with-gmp=/tools to mpfr configure line 3. modify gcc configure line to include --wth-gmp=/tools (--with-mpfr is not necessary, configure uses gmp location by default) 4. Modify gcc make command with one of the following LD_LIBRARY_PATH=/tools/lib:$LD_LIBRARY_PATH make or cat /etc/ld.so.conf EOF /tools/lib EOF make sed -i -e '@/tools/[EMAIL PROTECTED]' /etc/ld.so.conf -- -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GCC-4.3.1, Linux-2.6.26.2
On Wed, Aug 27, 2008 at 10:12 PM, Steve Crosby [EMAIL PROTECTED] wrote: On Wed, Aug 27, 2008 at 8:05 PM, Greg Schafer [EMAIL PROTECTED] wrote: Steve Crosby wrote: FYI: building them in the tools directory is going to be problematic. During the stage 1 build of gcc, the make system is unable to locate the libmpfr.so.1 library, and so aborts. snip LD_LIBRARY_PATH=/tools/lib:$LD_LIBRARY_PATH make this doesn't scale - the linux headers build (and I suspect everything else following gcc) also looks for the mpfr library whenever the compiler is invoked. Doing the /etc/ld.so.conf edit will work, which could be undone in the adjusting toolchain phase, but that does involve editing the host system, which may not be feasible for a live cd or restircted environment. Don't think exporting envvar for several packages is a great solution, so will restart with the embedded mpfr\gmp libs as suggested by Greg and see what happens from there. (although I *suspect* the same issue will arise with missing libraries after gcc build dir is removed). -- -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
GCC 4.3.1 SVN compilation summary
Update on previous thread: LD_LIBRARY_PATH isn't needed at all. I was compiling GPM\MPFR as shared libraries, whereas the method Greg proposed of embedding in the GCC framework does a static compile only. Either the embedding or the following work fine (although if used, embedding is required for both GCC pass 1 and 2) 1. Move GMP to after binutils 2. configure GMP with normal + --disable-shared 3. Move MPFR to after GMP 4. configure MPFR with normal + --disable-shared --with-gmp=/tools 5. configure gcc pass 1 with normal + --with-gmp=/tools (gcc pass 2 needs no changes, the ld LIB_PATH takes care of the location of gmp\mpfr) whether or not this is better is up to the editors, although it might simplify jhalfs building to have the libraries as seperate apps currently up to gawk install in Chapter 5, no new issues to report that are not already noted. -- -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GCC-4.3.1, Linux-2.6.26.2
On Tue, Aug 26, 2008 at 1:32 PM, DJ Lucas [EMAIL PROTECTED] wrote: DJ Lucas wrote: snip updated a local export of the book. I'm uploading my modified SVN export, rendered book, and patches in my home directory just in case anyone would like to review it. LFS-20080825/ The probably 'not so liked' changes are at the top of the changelog in big paragraphs, then Is this only for developers to test? I'm not familiar enough with the LFW server directory structure to guess a home directory URL, assuming it's publicly accessible. Having just yesterday completed a LFS Live CD 6.3 build into my new VMWare instance, I'm keen to test the latest SVN build over the next few days. -- -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Is 6.3 ready for release?
On 8/2/07, Ken Moffat [EMAIL PROTECTED] wrote: On Wed, Aug 01, 2007 at 02:53:59PM -0700, Dan Nicholson wrote: On 7/30/07, Ken Moffat [EMAIL PROTECTED] wrote: I got those failures on a single run (using jhalfs). I'm not sure what's causing the errors, but what's failing is `test -r /dev/fd/0' and `test -r /dev/stdin' (look at tests/test.right for the output that it's diffing to above). So, I suspect this has something to do with the su to the nobody user and how su handles these devices. But the last time I thought about this it hurt my head. It may have something even more to do with how our scripts are handling the user switching. These files both end up being symlinks to /dev/pts/0 (or whatever pts device you logged into) - and the perms for this are root:~# ls -l /dev/fd/0 lrwx-- 1 root root 64 2007-08-02 14:30 /dev/fd/0 - /dev/pts/0 root:~# ls -l /dev/stdin lrwxrwxrwx 1 root root 15 2007-08-03 02:22 /dev/stdin - /proc/self/fd/0 root:~# ls -l /proc/self/fd/0 lrwx-- 1 root root 64 2007-08-02 14:30 /proc/self/fd/0 - /dev/pts/0 root:~# ls -l /dev/pts/0 crw--w 1 root tty 136, 0 2007-08-02 14:30 /dev/pts/0 so the nobody user won't be able to read these devices. Not sure how you would work around that, unless you use login instead of su to start the nobody user doing the testing (which will change ownership of /dev/pts/x and hence the tests will pass) -- -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Little note on psmisc
On 5/11/07, M.Canales.es [EMAIL PROTECTED] wrote:
El Jueves, 10 de Mayo de 2007 21:11, Bruce Dubbs escribió:
Looking at the source and then running `genl -help` I get
$ ./genl -help
Usage: genl [ OPTIONS ] OBJECT | help }
where OBJECT := { ctrl etc }
OPTIONS := { -s[tatistics] | -d[etails] | -r[aw] }
But I have no idea what that means.
After looking also at include/linux/genetlink.h, looks like genl is a tool for
monitoring generic netlink linux sockets (what is that??), similar to what
ip monitor do for devices, addresses, and routes.
Netlink is a method of communicating between kernel and userspace I
believe - the netfilter modules use this new technology to replace the
old logging methods. Basically you setup a socket in the kernel, and
then userspace can use that to communicate to a kernel module - this
can be bi-directional and multi-cast too, so you can hang a userspace
process on a netlink socket and receive output from the kernel module
- useful for accounting, audting, etc.
--
-- -
Steve Crosby
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: LTP failure
results here from an older system (specifically an LFS dev version from around mar 2006) mincore011 PASS : expected failure: errno = 22 (Invalid argument) mincore012 PASS : expected failure: errno = 14 (Bad address) mincore013 FAIL : call succeeded unexpectedly mincore014 PASS : expected failure: errno = 12 (Cannot allocate memory) current kernel version is (recently rebuilt to add USB support): Linux lfsbuild 2.6.15.6-LFS #7 Fri Mar 2 00:55:33 NZDT 2007 i686 i686 i386 GNU/Linux On 3/21/07, Bruce Dubbs [EMAIL PROTECTED] wrote: I've been trying to figure out why the attached file fails on my LFS systems. It does not fail on FC or RHEL kernels. I'd appreciate it if some of you could run the attached program ans send me the results. You just run the binary. If you don't want to do that, the full source to is at http://prdownloads.sourceforge.net/ltp/ltp-full-20070228.tgz?download -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page -- -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Proposal for an LFS-6.3
On 2/8/07, Alexander E. Patrakov [EMAIL PROTECTED] wrote:
Randy McMurchy wrote:
The current LFS SVN has an entirely upgraded toolchain, and many
updates to core packages since the 6.2 release. I just built it and
it appears rock solid.
That's because you didn't use any CFLAGS. If you had -Os in CFLAGS, you
would hit ticket #1935.
Hmmm...the book does state that you should unset any CFLAGS variables
before compiling, since some packages don't behave well - I realise
that's not what your referring to, but the implication is that if you
choose to use non-package specified CFLAGS, your expected to be able
to provide some of your own support.
Not that it wouldn't be good to get the fixes in place, but that
shouldn't be a showstopper for book release
Booted without a hitch (using Linux-2.16.20,
Udev-105 and current LFS bootscripts). So far, everything seems really
solid.
Well, there are some udev-related bugs that need to be entered into Trac.
Basically:
* The udev bootscript runs, and creates temporary rules for newly-added
network cards in /dev/shm
* The mountfs script mounts tmpfs on top of /dev/shm, hiding temporary
rules!
* The udev_retry script is supposed to copy temporary rules from /dev/shm
to the permanent location, but doesn't find them.
Reordering the scripts is not an option, because the purpose of the
udev_retry bootscript is also to retry uevents that failed due to
unavailable /usr. So, it looks like we have to move /dev/shm mounting from
fstab to the udev script.
Thats not the experience I have here - temporary rules are created in
/dev/.udev, and correctly copied from there to the /etc/udev/rules.d
directory by the udev_retry bootscript. Or is this related to network
cards only? (my temporary rules are for cd-rom naming)
This extract is from lfs-bootscripts-20070203 udev_retry
-
# From Debian: copy the rules generated before / was mounted
# read-write:
for file in /dev/.udev/tmp-rules--*; do
dest=${file##*tmp-rules--}
[ $dest = '*' ] break
cat $file /etc/udev/rules.d/$dest
rm -f $file
done
# Re-trigger the failed uevents in hope they will succeed now
/sbin/udevtrigger --retry-failed
-
--
-- -
Steve Crosby
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Book text updates
On 8/27/06, Mark Rosenstand [EMAIL PROTECTED] wrote:
On Tue, 2006-07-18 at 07:31 -0700, Dan Nicholson wrote:
On 7/18/06, Randy McMurchy [EMAIL PROTECTED] wrote:
-install -dv -m 1777 /tmp /var/tmp
+install -dv -m 1777 {/var,}/tmp
This syntax looks wrong to me. Seems it would create a /var/tmp
dir but not /tmp.
It's correct. {/var,} expands to /var and .
I think this obfuscation of the command is unneccessary, since the paths
are so short (you save 2 chars and in the keys you'll have to strike are
placed at worse positions) and it's also a bash-ism (which I don't mind
One of the original purposes of the LFS project was to teach you how
to build a Linux From Scratch system, with the emphasis on teach. It's
not intended to be a straight cut and paste formula, and the
opportuniy is taken in several places to expose the reader to some of
the shortcuts and alternate command line options they may have been
unaware of previously.
The bash'ism comment isn't necessarily valid - at this point in the
book, you're in a chroot environment, in a bash shell, so use of bash
specific commands is certainly valid. If you have chosen to not
install bash, then your expected to also know what impact such
deviation will have.
--
-- -
Steve Crosby
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Udev incorrectly generating entries in /dev/.udev/failed
On 7/26/06, Alexander E. Patrakov [EMAIL PROTECTED] wrote:
Anthony Wright wrote:
When udev tries to create entries in some cases it uses modprobe, and if
this fails it causes an entry to be created in /dev/.udev/failed/
Ignore the issue. It is prsent in all distros. Of course, this is
fixable by replacing the current modprobe rule with the following:
ACTION==add, ENV{MODALIAS}==?*, RUN+=/bin/sh -c '/sbin/modprobe
$env{MODALIAS} || true'
(and similar changes to other rules) but I consider calling /bin/sh a bloat.
--
Alexander E. Patrakov
you can either remove the modprobe rules from the rules directory, or
link /sbin/modprobe to /bin/true - I have the same issue with a
firewall build using no modules, and just remove the module based
ruleset.
--
-- -
Steve Crosby
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [Fwd: Re: LFS 6.2-pre2 Released]
On 7/25/06, Bruce Dubbs [EMAIL PROTECTED] wrote: I'm not sure if this is best addressed in LFS or BLFS. -- Bruce It's a core LFS bootscripts issue, so LFS is probably the best location Original Message Subject: Re: LFS 6.2-pre2 Released Date: Mon, 24 Jul 2006 22:42:24 +0200 From: Thomas Seeling [EMAIL PROTECTED] If the shutdown procedure kills the processes in the wrong sequence (e.g. the nmbd child first) then the parent spawns a new child and the killproc function thinks that the shutdown failed. I guess this is only an aesthetical problem, but I solved it by sort'ing the ps output before giving it to the kill function. You should be able to write the pids used by the app to a file, and pass that as an argument to killproc - that way you can decide which order you want them killed in your local app bootscript, and not have to change killproc at all. Without having the bootscripts handy, i think it the syntax is killproc -p pidfile application -- -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: OFFICIAL PROPOSAL.
On 5/29/06, Ag Hatzimanikas [EMAIL PROTECTED] wrote: On Sun, May 28, at 04:59:14 Ag Hatzimanikas wrote: I propose the creation of a new udev/bootscript/kernel/doc team. I nominate Alexander Patrakov as the new Leader of this project, and also Dan Nicholson, DJ Lucas, Ken Moffat as members of the team. snip I will come back to my house late night, and if there is no serious reason against the idea, the voting procedure will come to an end. It's 09.31 (here local time),and I guess 12-15 hours from now. hmm - did LFS gain a constitution while I wasn't watching? Time Limits on a volunteer project run by mailing list and IRC conversations? Voting? Democracy? Surely the benign dictatorship model we had prior to this radical political change was working okay? -- -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Kernel Headers Script [was: Rally the Troops LFS/BLFS/CLFS/Livecd too]
On 5/4/06, Jim Gifford [EMAIL PROTECTED] wrote: I probably need to document that a little better. Basically you untar your program and tell it ./headers_list iptables-1.3.5 and it creates a report of all the headers needed for a build. That makes more sense ;) resulting asm-headers and linux-headers attached. Note that the find command in the header_list script needed altering to escape the filenames, or it reports an error about paths preceeding options. i.e find * -name \*.c and find * -name \*.h -- -- - Steve Crosby asm-headers Description: Binary data linux-headers Description: Binary data -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Kernel Headers Script [was: Rally the Troops LFS/BLFS/CLFS/Livecd too]
On 5/4/06, Jim Gifford [EMAIL PROTECTED] wrote: I probably need to document that a little better. Basically you untar your program and tell it ./headers_list iptables-1.3.5 and it creates a report of all the headers needed for a build. also below are results for ulog, a companion program to iptables - version 1.24 of ulog is used in my setup, however a v2.0beta is being developed by the netfilter team. steve:/usr/src# cat asm-headers asm/types.h steve:/usr/src# cat linux-headers linux/netfilter_ipv4/ipt_ULOG.h linux/netlink.h -- -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Rally the Troops LFS/BLFS/CLFS/Livecd too
On 5/4/06, Matt Darcy [EMAIL PROTECTED] wrote: steve crosby wrote: On 5/1/06, Bryan Kadzban [EMAIL PROTECTED] wrote: snip a setup. The sticking point would be programs that include linux/x.h or asm/x.h, if there are any. And it sounds like there are glibc alternatives to all of those headers anyway, so it would be the program that's broken. (Unless it's Linux-specific.) iptables is one such application - currently non functional with jim's script created headers, but have yet to identify why. -- -- - Steve Crosby Once again a totally pointless discussion about iptables and specific headers, What part of this threads topic was not clear ? snip My intent was to identify that one of the options provided in the thread (Jim's work with the linux headers) has problems, as it's currently not working with certain applications outside of LFS. Perhaps I should have been more clear in the comment I made. I'll leave the discussion about the use\utility of discussions in mailing lists well alone in the interests of world peace. -- -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Kernel Headers Script [was: Rally the Troops LFS/BLFS/CLFS/Livecd too]
On 5/4/06, Jim Gifford [EMAIL PROTECTED] wrote: steve crosby wrote: My intent was to identify that one of the options provided in the thread (Jim's work with the linux headers) has problems, as it's currently not working with certain applications outside of LFS. snip I think I was able to build iptables with the 00.50 and above script. So let me know. I used the pre-generated tarball 2.6.16.13 rather than the actual script, which failed in the iptables dependency checks (on netfilter_ipv4/ipt_TOS.h) FYI: using LFS trunk, with glibc 2.4, gcc 4.1.0, iptables 1.3.5 I'll try using the native script instead and see what I get. For reference the LLH maintained the entire linux\netfilter*\* header structure, and that works fine. -- -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Kernel Headers Script [was: Rally the Troops LFS/BLFS/CLFS/Livecd too]
On 5/4/06, Jim Gifford [EMAIL PROTECTED] wrote: Steve, I think I got it covered in the 00.52, I'll be posting it shortly. still no joy linux/dccp.h missing - I added that, and then this occurs extensions/libipt_connmark.c: In function 'init': extensions/libipt_connmark.c:52: error: 'NFC_UNKNOWN' undeclared (first use in this function) extensions/libipt_connmark.c:52: error: (Each undeclared identifier is reported only once extensions/libipt_connmark.c:52: error: for each function it appears in.) make: *** [extensions/libipt_connmark_sh.o] Error 1 checking, this define is declared in linux/netfilter.h, however the sanitised netfilter.h contains: #ifndef LINUX_NETFILTER_H /* Empty */ #endif so still some work to do... -- -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Kernel Headers Script [was: Rally the Troops LFS/BLFS/CLFS/Livecd too]
On 5/4/06, Jim Gifford [EMAIL PROTECTED] wrote: Ok, got those changes in. Thanx for the reports Steve, this is what I need. no worries - with those changes (dccp.h, netfilter.h) iptables (and ulog) compile fine. Diff attached for headers script for reference diff -Naur headers.sh.orig headers.sh --- headers.sh.orig 2006-05-04 15:44:02.0 +1200 +++ headers.sh 2006-05-04 15:44:06.0 +1200 @@ -420,7 +420,7 @@ LINUX_HEADERS=adfs_fs.h adfs_fs_i.h adfs_fs_sb.h affs_fs.h agpgart.h apm_bios.h atalk.h atmapi.h atmarp.h atmclip.h atmdev.h atm_eni.h atm.h atm_idt77105.h atm_nicstar.h atmioc.h atmsap.h atmsvc.h atm_tcp.h atm_zatm.h atmlec.h atmmpc.h auto_fs.h auto_fs4.h auxvec.h bfs_fs.h bitops.h blkpg.h cache.h capability.h - calc64.h cdrom.h coda_fs_i.h compat.h cramfs_fs.h cramfs_fs_sb.h dcache.h devpts_fs.h dirent.h + calc64.h cdrom.h coda_fs_i.h compat.h cramfs_fs.h cramfs_fs_sb.h dcache.h dccp.h devpts_fs.h dirent.h dnotify.h efs_fs.h efs_fs_i.h efs_fs_sb.h elf.h errno.h ethtool.h ext2_fs.h ext2_fs_sb.h ext3_fs.h ext3_fs_i.h ext3_fs_sb.h fb.h fcntl.h fd.h filter.h fs.h gen_stats.h hdreg.h hpfs_fs.h if.h if_arp.h if_arcnet.h if_bonding.h if_bridge.h if_cablemodem.h if_ec.h if_eql.h if_ether.h if_fddi.h if_fc.h @@ -428,7 +428,7 @@ if_slip.h if_strip.h if_tr.h if_tun.h if_tunnel.h if_vlan.h if_wanpipe.h if_wanpipe_common.h in.6 in6.h in_route.h inet_diag.h init.h inotify.h input.h interrupt.h ip.h ip6.h ioctl.h iso_fs.h ipv6.h ipv6_route.h ip_mp_alg.h irda.h isdn.h jiffies.h jffs2_fs_i.h jffs2_fs_sb.h joystick.h kd.h kdev_t.h - kernel.h keyboard.h limits.h linkage.h lp.h major.h minix_fs.h msdos_fs.h netdevice.h netfilter_ipv4.h + kernel.h keyboard.h limits.h linkage.h lp.h major.h minix_fs.h msdos_fs.h netdevice.h netfilter.h netfilter_ipv4.h netlink.h netrom.h ncp_fs.h ncp_fs_i.h ncp_fs_sb.h nfs.h nfs_fs.h nfs_fs_i.h nfs_fs_sb.h nfs2.h nfs3.h nfs4.h openprom_fs.h param.h patchkey.h pci.h pipe_fs_i.h pkt_cls.h pkt_sched.h poll.h posix_types.h ppp-comp.h ppp_defs.h preempt.h prctl.h proc_fs.h ptrace.h qnx4_fs.h raw.h rbtree.h @@ -441,7 +441,7 @@ NOSANTIZE_ASM_HEADERS=types.h NOSANTIZE_LINUX_HEADERS=types.h byteorder/big_endian.h byteorder/little_endian.h BLANK_HEADERS=linux/autoconf.h linux/agp_backend.h linux/compiler.h linux/config.h linux/list.h linux/mmzone.h - linux/netfilter.h linux/pagemap.h linux/percpu.h linux/syscalls.h linux/uio.h linux/utime.h + linux/pagemap.h linux/percpu.h linux/syscalls.h linux/uio.h linux/utime.h ROOT_HEADERS=linux/elf.h linux/signal.h ASM_SYS_HEADERS=io.h SYS_HEADERS=linux/resource.h linux/socket.h linux/time.h linux/wait.h -- -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Kernel Headers Script [was: Rally the Troops LFS/BLFS/CLFS/Livecd too]
On 5/4/06, Jim Gifford [EMAIL PROTECTED] wrote: Steve, I just added a headers_list script that will look at the sources and pull all the headers and put them into a report. Let's run that and compare what I have in the script now to see what's missing. http://ftp.jg555.com/headers/headers_list Sorry, I don't understand from that what\where the script is supposed to be run. The only changes I made to the headers script are - add dccp.h and netfilter.h to the LINUX_HEADERS variable - remove linux/netfilter.h from the BLANK_HEADERS variable. using those changes, I created a new tarball from the 2.6.16.13 raw headers, built LFS, and iptables is able to compile fine. -- -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: rule verification
On 5/3/06, Archaic [EMAIL PROTECTED] wrote: On Tue, May 02, 2006 at 11:58:44PM -0500, Bruce Dubbs wrote: snip As a related issue, but perhaps off topic, does anyone know how to reduce the number of tty devices? My system shows tty0..tty63 and I don't think I need nearly that many. I found it once, but forget where. It was a c file in the kernel. A #DEFINE, IIRC. from tty.h #define MAX_NR_USER_CONSOLES 63 /* must be root to allocate above this */ -- -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: udev branch: /sbin/udevstart not installed with 0.87
On 3/19/06, Andrew Benton [EMAIL PROTECTED] wrote: steve crosby wrote: The program is built, but not installed (or needed later) - just run it from the current directory (e.g. instead of /sbin/udevstart use ./udevstart) No, there's no need, the instruction to run udevstart is just a hangover from when we used to use it. If you don't activate udev, then you have no disk devices later when you come to setup grub. -- -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: udev branch: /sbin/udevstart not installed with 0.87
On 3/18/06, Kevin White [EMAIL PROTECTED] wrote: I'm playing around with the udev branch. At the end of the instructions for installing udev-087, it says: Run the udevstart program to create our full complement of device nodes. /sbin/udevstart But, in udev-087, udevstart isn't installed anymore. So, now what? The program is built, but not installed (or needed later) - just run it from the current directory (e.g. instead of /sbin/udevstart use ./udevstart) -- -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bug in LFS?
On 9/13/05, Jeremy Huntwork [EMAIL PROTECTED] wrote: Hey Everyone: I've run across something that I'm pretty sure isn't supposed to happen. On two different systems, when I have a CD mounted, I have been able to push the eject button and eject the CD. This has happened on both my Some older CDROM drives don't fully support the standards - as such, they ignore the lock command (amongst other more important ones!) Use http://cdctl.sourceforge.net/ and see if that can lock the drive door - if not, it's a firmware thing (or a bug in the kernel cdrom driver). -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] Udev configuration changes
On 9/14/05, Matthew Burgess [EMAIL PROTECTED] wrote: Hi guys, Archaic and I have put our heads together to try and come up with a more reasonable set of Udev rules. These are based on the following criteria: snip Good work guys - tthanks for creating the initial ruleset. # /etc/udev/rules.d/25-lfs.rules: Rule definitions for LFS. # Create the /dev/cdrom symlink. BUS=ide, KERNEL=*[!0-9], PROGRAM=/bin/cat /proc/ide/%k/media, RESULT=cdrom, NAME=%k, SYMLINK=cdrom In addition to the mentioned multiple CDROM and DVD\CDWriter comments already made, I'll add that we need to cater for SCSI CD devices too ;) # Core kernel devices ## Unchanged KERNEL==random, MODE==0444 KERNEL==urandom, MODE==0444 Lots of the rules that follow might be able to take more advantage of the regex desciptions. e.g. KERNEL==[u,]random MODE=0444 That however does make the file less readable, and isn't a huge advantage memory wise. And to respond to some of the other issues raised: Originally, we created the LFS udev rules to match the base functionality of the MAKEDEV package. Could we perhaps resurrect that package, except that the new MAKEDEV would generate a udev rules file, rather than the nodes themselves? Possibly allow a prompt option to makedev which asks what nodes you want, and a makedev LFS\BLFS so the actual node rules can be maintained by the appropriate development teams - just a thought. Note also that editing the default ruleset supplied by LFS is not necessary - multiple rules files are perfectly acceptable, as long as the rules of precedence are considered. -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] Udev configuration changes
On 9/14/05, steve crosby [EMAIL PROTECTED] wrote: snip Note also that editing the default ruleset supplied by LFS is not necessary - multiple rules files are perfectly acceptable, as long as the rules of precedence are considered. Replying to myself ;) Does it make sense to have *two* rule files? 025-lfs.rules and 026-blfs.rules? Each dev team can manage the appropriate rules files to set the rules as they need them. In the BLFS Post-LFS section, a copy the 026-blfs.rules file comment would cover all the bases? That way the BLFS dev team could manage and test the required BLFS specific rules in a signle file, and make appropriate changes as needed. -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bogus usage of gcc --print-file
On 8/15/05, Greg Schafer [EMAIL PROTECTED] wrote: 1) `--print-file' is undocumented (therefore could break anytime) fair enough: suggested changes are: Chapter 5 gcc -dumpspecs | sed -e 's@ /lib/ld-linux.so.2@ /tools/lib/[EMAIL PROTECTED]' tempfile gcc -specs=tempfile rm tempfile Chapter 6 gcc -dumpspecs | sed -e 's@ /tools/lib/ld-linux.so.2@ /lib/[EMAIL PROTECTED]' -e '[EMAIL PROTECTED]:[EMAIL PROTECTED]/usr/lib/@g' tempfile gcc -specs=tempfile rm tempfile -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bogus usage of gcc --print-file
On 8/16/05, Matthew Burgess [EMAIL PROTECTED] wrote: Matthew Burgess wrote: GCC-3.x appears to support -dumpspecs Obviously (now I've read the two books!), that won't tell us where the specs file lives, which is what we need to know! For a clearer Why do we need to know? we can simply do as I posted earlier, and sed the dumpspecs stream, then input the results directly to the specs with with -specs= - let gcc handle updating the actual file -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Coreutils binary locations
On 8/15/05, Matthew Burgess [EMAIL PROTECTED] wrote: snip work. The ideal solution would be to figure out a way of getting the test/udev-test.pl script to figure out whether it should call /usr/bin/test or /bin/test. However, I'm only going to invest time in this if someone can convince me of why we *need* to move 'test' and '[' to /bin. Well, now you can decide at your leisure about where you want them. Attached patch modifies udev-test.pl to find the binary and replace the correct path in the rules array. If a required external binary can't be found, the test program will now abort with an error, except in the case of tree, where an ls -laR will be performed instead. The patch needs a proper LFS header applied and sending upstream (hint, hint, nudge, nudge). Tested here on udev-067 without issue. -- - Steve Crosby udev-067-fix_paths-1.patch Description: Binary data -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] Add CrackLib to Chapter 6 LFS
On 8/5/05, Jeremy Huntwork [EMAIL PROTECTED] wrote: Randy McMurchy wrote: Hi all, Is it a common enough (ie, several mainstream distros include it by default) package to mandate that every LFS user build and install it? Are there any disadvantages to including it in the LFS book? Yes, extrememly common - not only Linux but other UNIX vendors provide dictionary checking of passwords these days. Of course, they also include PAM as well, but we aren't discussing that. Probably the best method for deciding the utility of a package change in base LFS is the method you mention - what are the pros and cons? Pro(s): Increases the default security of the base LFS distribution. This is where we ask the user to *set* the root passwd, so probably the best place to include the capability of dictionary checking. Shadow is one of the few base LFS packages that BLFS touches, so it would be benefical to move that to LFS, so that BLS implementations have less rick of breaking the main system. Con(s): It's more management overhead (admittedly minor) More disk space usage Any one have any others? Oh, and +1 from me for inclusion of cracklib in LFS (but NOT Linux_PAM!) -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] Add CrackLib to Chapter 6 LFS
On 8/5/05, Randy McMurchy [EMAIL PROTECTED] wrote: Randy McMurchy wrote these words on 08/04/05 19:12 CST: This is a stretch. To the best of my knowledge, all the CrackLib library does is check that the password a user enters during the Regardless, if the end user doesn't like/want the policy, all that's required is to skip this package installation, much the same as people can currently skip things like gettext, module-init tools, etc. -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Upcoming util-linux
Just a heads up - util-linux 2.13 will remove several items, as per the following changelog entry for pre1 Changes: GNU autoconf/automake/libtool are now used for building. schedutils were added. Support for curses implementations other than ncurses was removed. The arch, passwd, rescuept, and setfdprm programs were removed. mkminix-0.1/ was removed. Misc fixes and documentation updates were made. A translation was added for the vi locale. The translations for the ca, de, fi, fr, it, nl, ru, and tr locales were updated. This may impact some apps that use arch in their configure stage (I know at least perl used arch at some stage) -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bzip2 documentation
On 8/4/05, Randy McMurchy [EMAIL PROTECTED] wrote: Attached is a patch that can be installed using the LFS conventional method of 'patch -Np1 -i ../patchname' which will install the docs to /usr/share/doc/bzip2-1.0.3. I suggest this patch is incorporated into the default LFS builds. Keep in mind that this patch will require some maintenance when the Bzip2 package is updated, as the version number is hard-wired into the patch. I couldn't find any version entity or anything in the Makefile that I could reference to get a version number. Updated version attached, using DISTNAME makefile variable for version control (and other minor enhancements) -- - Steve Crosby bzip2-1.0.3-install_docs-2.patch Description: Binary data -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: charset/language/fluxbox
On 7/16/05, Alexander E. Patrakov [EMAIL PROTECTED] wrote: snip I suspected that the new text about locales at http://www.linuxfromscratch.org/lfs/view/6.1/chapter07/profile.html is still wrong. Judging from the message, it is evident that Thomas Trepl has never tried [EMAIL PROTECTED] (case-sensitive), LC_ALL unset (that's what the book recommends now). If that works, there is no need to change the text. My testing here shows that X accepts such locale name. Background: glibc treats charset names in the locale names case-insensitively and ignores hyphens. So, [EMAIL PROTECTED] and [EMAIL PROTECTED] are the same thing for glibc. But not for applications/libraries that parse locale names themselves, without the help from glibc. Xlib is one of those picky libraries, and fluxbox is just a victim. LFS should provide readers with the means to guess the locale name that will be accepted by such picky packages. So, if I read that correctly, the Xlib library is broken, and you'd like the LFS instructions to (possibly) be modified to workaround the problem? Something like: Some applications and libraries that use locale information directly instead of through the glibc interface incorrectly rely on the LC variables you have set above being case-sensitive. You should run the locale -something command to get the correct value to use for the LC variables to work around issues with these broken applications and libraries. I'm assuming the Xlib maintainers have been notified of the problem as well? -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Please mention prerequisites: bison flex
On 7/6/05, Kim McCall [EMAIL PROTECTED] wrote: snip that there ought to be some kind of documentation of what development tools are required in order to build LFS. There already are: from the binutils page Installation depends on: Bash, Bison, Coreutils, Diffutils, Flex, GCC, Gettext, Glibc, Grep, M4, Make, Perl, Sed, and Texinfo -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Kernel 2.6.12
On 20 Jun 2005, you wrote in lfs.dev:
Not sure if this is related.
I upgraded my old 586 to kernel 2.6.11.12 with lfs-bootscripts-3.2.2
(+ iproute etc) - the base lfs on it is 5.1. It has two eth ports, as
it's my firewall. The sequence of initialisation (ifup's) is now
critical.
Not sure about why you were seeing bootscript differences, but you can
control the order of interface raising by using custom udev rules to
name the interfaces as they are discovered. I use this technique on my
i586 firewall to ensure the firewall rules apply the correct rules to the
local and internet interfaces.
Something like the following: (obviously, using a real MAC Address for each
NIC ;)
KERNEL=eth*, SYSFS{address}=MA:CA:DD:RE:SS:00, name=internal
KERNEL=eth*, SYSFS{address}=MA:CA:DD:RE:SS:01, name=external
I can then reliably assume that all processing on the interface named
external refers to the internet facing NIC ;)
- --
Steve Crosby
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: SBU calculations
On 17 Jun 2005, you wrote in lfs.dev: On Thu, Jun 16, 2005 at 08:32:56PM +0100, Matthew Burgess wrote: Well, personally I measure them using the following simple rule: 1. Start timing immediately after the tarball has been unpacked. 2. Don't time the running of any testsuite commands. 3. Stop timing immediately after 'make install' has completed. This applies for all packages, including pass 1 of binutils in chapter I beg to differ. Both glibc pages have time consuming post-make install commands. Both llh pages have no make install. util-linux in chapter 5 doesn't have a make install. perl in chapter 5 doesn't have a make install. zlib has 2 make installs. mktemp has 2 make installs. texinfo has 2 make installs. e2fsprogs has 2 make installs. hotplug has no make install. That's 11 pages that might lead to confusion. First, Are users expected to be measuring package build times? I expect the SBU calculations for the BOOK involve the end user measuring binutils in Chapter 5, then using that as a GUIDE on how long remaining packages will take, rather than actually caluclating their own as they go. Certainly the editors\testers need to be able to calculate the actual SBU's, but they can refer to seperate (editors guide?) instructions for that surely. Second, SBU's are a wild-ass guess. The methodology of calculating SBU's is fine, but the application of someone else's build time measurements bear only rough resemblance to my system - specifically because of architecture, disk, memory, CPU cache differences etc. Do we really need to care about 10% variances in build times for the initial SBU, when you can get greater variance than that due to other variables in the system. (The point being, should we really care that much about how accurate the SBU is, given it's a finger in the air, rough-guide anyway) - -- Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: lfs-bootscripts (networking)
On 07 May 2005, you wrote in lfs.dev: Some notes as I attempt to make the lfs bootscripts more wireless-friendly: Currently the networking scripts allow only for one default gateway. However, each interface should have it's own. When trying to do that manually with ip, it bombs. Since I still prefer net-tools I decided to try it with route and it works swimmingly. After discussing this with Jim, he said he would send a bug report upstream to fix ip. Once this is done, the code will need to be changed to only grep for a default gateway on the interface that is being setup, not all interfaces. I'm confused, or your using terminology I'm not understanding - by definition, a default gateway is where I send packets that I don't know how to route - and therefore there can only be one default gateway. Perhaps you meant multiple routes between networks, which can already be added with ip. -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
RE: lfs-bootscripts (networking)
On 07 May 2005, you wrote in lfs.dev: -Message d'origine- snip I'm confused, or your using terminology I'm not understanding - by definition, a default gateway is where I send packets that I don't know how to route - and therefore there can only be one default gateway. Perhaps you meant multiple routes between networks, which can already be added with ip. Multiple interfaces = multiple gateways. You misunderstand (or are using terminology I'm not understanding). A default gateway has a very specific meaning in networking terminology: Assume a network like this: eth0: 192.168.1.0\24 eth1: 192.168.2.0\24 If a packet comes from eth0, addressed to 192.168.20.24, where shall I send it, since my routing table has no knowledge of that address? The answer is that I need to define an interface (and only one) to which I should send packets addressed to an unknown network. It is assumed that a router on this interface will be better placed to handle the request. Having multiple *default* gateways makes no sense - if I get a packet that I do not know how to route, which of the multiple default gateways should I send it to? If there is some form of filtering logic I can apply to the packet to deduce which interface to route it to, then by definition the packet is no longer unknown, since I have a defined route to send it down (and static routing of this nature is very common) Hope thats clearer - the default route is where I send a packet that I don't otherwise know how to handle. Note that I'm not saying multiple routes can't be configured, just that I would prefer we not say multiple default routes, since that has special meaning as per above. - -- Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
New Cross-LFS book - what about the printed version?
I'm sure it's been considered, but I haven't seen anything about how it will be handled, so I'll ask anyway... The question is, with the new multi-choice cross-lfs book being worked on, how are we planning on producing a hardcopy version? Questions regarding the linear flow of the book are resolved by using smart XML processing, but I've yet to see that technology in paperback ;) If no-one has considered it, I'd like to suggest the use of pageheading graphics which the user can follow, depending on their target configuration. i.e. If building for sparc, you would use the sections in the book (linearly) that have either the sparc graphic, or the all graphic in the section heading. Also as an aside, are there plans to resurrect the news-mail gateway, or will the server remain in read-only mode? My primary access to the [b,h]lfs lists is via news, not mail, and my reader of choice does not support replying via email, so I can't intelligently respond to threads easily... ;( -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Binutils failure in Chapter 5
Steve Crosby [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: Robert R. Russell [EMAIL PROTECTED] wrote in news:d0lq7l$ht0$1 @belgarath.linuxfromscratch.org: Why is stripping the host binaries the issue? My Febuary 22, 2005 rebuild of Gentoo 2004.3-unstable had absolutely no issues with any of the LFS-BOOK-SVN-20050228-HTML chapter 5 packages except flex, it would not compile so I am using flex-2.5.4a. the host toolchain is GNU C Library stable release version 2.3.4 GNU CC version 3.4.3-20050110 (Gentoo Linux 3.4.3.20050110, ssp-3.4.3.20050110-0, pie-8.7.7) binutils GNU ld version 2.15.92.0.2 20040927 There are 2 issues (note: I don't fully comprehend the issues, just re- gurgitating and summarising various posts from mailing lists): snip LFS 6.0 suffers from this issue, as it uses the broken strip (but not the broken ld). When using LFS6.0 as a host to build LFS-SVN, which has a fixed ld, it rightly complains and refuses to link. thats a thinko - should read: LFS 6.0 suffers from this issue, as it uses the broken strip (and the broken ld). When using LFS6.0 as a host to build LFS-SVN, which has a fixed ld, it rightly complains and refuses to link. -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS on Sun Ultra5
[EMAIL PROTECTED] wrote in news:OFE9389F4D.EB5D7A58- [EMAIL PROTECTED]: Steve Crosby wrote: For the LFS build - is there a recommendation about building LFS from Linux or Solaris? MUCH easier from linux ;-) There is this little matter of no ext2 write support under solaris... (genext2fs may help out here... I haven't got that far yet) snip much convoluted build processes that make my brain hurt okay - so from Linux it is ;) Instaling Aurora Linux now because it was handy, any other recommendations for a host distro? Anyhoo, let us know how you go :-D Regards [R] -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Binutils failure in Chapter 5
Randy McMurchy [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: Steve Crosby wrote these words on 03/07/05 20:12 CST: 1. build the initial binutils and gcc in chapter 5 using dynamic libs, rather than static (this avoids the stripped libc.a issue). 2. use binutils prior to 2.15.91.0.2 in the initial chapter 5 (this results in binutils ignoring the fact the symbols in libc.a on the host are borked, but by chance that's the right option). 3. Just rebuild and replace libc.a on the host - none of the other glibc libraries\files are relevant to this issue. Shouldn't there be a note in the current SVN book to help out with this? I mean this is going to be a *huge* issue a little bit later on when folks start trying to use LFS-6.0 to build the next version. All three of the suggestions above are not just a trivial matter. I think it really sucks that one can't use the most recent prior version of LFS as a host to build the current version. This is something that needs to be addressed pronto. :-) Bug 1061 created with suggested text (compiling binutils\gcc shared) - note that I haven't the experience with the toolchain to indicate if this is a correct fix, and since it's a toolchains issue, will need some serious brainpower\testing before the next release. -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
LFS on Sun Ultra5
I have a Sun Ultra 5 fresh out of it's packaging, with 256MB RAM, 400Mhz UltraSparcIIi CPU and 9GB IDE HDD. I'd like to install LFS on it, in addition to Solaris and a Linux Distro. For the LFS build - is there a recommendation about building LFS from Linux or Solaris? The machine will end up being a playtoy for the missus and kids, so not to worried about having to rebuild every now and then. Just looking for some pointers to doco/info, as I'll start the building in the next few days. -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SBU and Disk Usage script-foo
Bruce Dubbs [EMAIL PROTECTED] wrote in
news:[EMAIL PROTECTED]:
Steve Crosby wrote:
Bruce Dubbs [EMAIL PROTECTED] wrote in
news:[EMAIL PROTECTED]:
Steve Crosby wrote:
I've added some script-foo to my build scripts to automatically
generate SBU's, Disk Usage and Installed Files details, and am
sharing below.
snip
before2=`df -k $LFS | grep $LFS | sed -e s/ \{2,\}/ /g | cut -d' '
-f3`
in Chapter 6 LFS chroot, the /etc/fstab doesn't exist, so df -k fails
echo `du -k ../$PROGRAM.tar.gz` size | tee -a ../build.log
after2=`df -k $LFS | grep $LFS | sed -e s/ \{2,\}/ /g | cut -d
-f3` echo $(($after2-$before2)) kilobytes / build size - $PROGRAM \
| tee -a ../build.log
in Chapter 5 LFS, the LFS user doesn't have perms for most of /proc,
so du- k spits a lot of errors, and df -k fails in Chapter 6 as per
above.
but thanks for the comments.
If you have $LFS defined, in Chapter 5, as instructed by the book, it
doesn't search /proc. In Chapter 6, s:$LFS:/:.
You don't need fstab if you specify the mount point.
I've been using this method without problems for about two years.
-- Bruce
*lightbulb*
Thanks - I was doing a df -k /mnt/lfs in the chroot, instead of a df -k /,
and of course that was reporting an error.
-- -
Steve Crosby
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Module-Init-Tools-3.1
Gerard Beekmans [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: snip commit. It might take a day or two before there might be time again. I'd rather get the package in without updating sizes, SBUs, and descriptions, than wait longer to get the update. snip For what it's worth, here are some Chapter 5 SBU's for LFS-SVN-20050219 (Chapter 6 tomorrow), with the following exceptions binutils is at 2.15.94.0.2.2 findutils is at 4.2.18 flex is patched to debian-fixes-4 using --without-csharp instead of --disable-csharp for gettext Host system is a LFS-SVN from January-ish, Host machine is a Pentium-M 1.6Ghz, *however*, it's running as a VMWare Workstation 4.5.2 build 8848 guest on a Windows XP SP1 laptop, with 512Mb RAM assigned to the Linux VM. (Yeah, thats an ugly way to do it - but it works, and it's what I have available ;) It also probably means the SBU's aren't worth a lot, but it's another data point anyway. Also, what's the recommended method of obtaining disk usage stats? total installed size, including sources? I'm building the full LFS system most every day, and can easily script that sort of thing to produce output that might be useful (e.g. SBU, disk usage, installed programs, etc) binutils-static 1.00 SBU gcc-static 2.41 SBU linux-libc-headers 0.01 SBU glibc 3.77 SBU gcc 2.05 SBU binutils1.11 SBU gawk0.19 SBU coreutils 0.56 SBU bzip2 0.01 SBU gzip0.04 SBU diffutils 0.11 SBU findutils 0.15 SBU make0.09 SBU grep0.09 SBU sed 0.11 SBU gettext 1.08 SBU ncurses 0.42 SBU patch 0.03 SBU tar 0.18 SBU texinfo 0.16 SBU bash0.33 SBU m4 0.05 SBU bison 0.14 SBU flex0.87 SBU util-linux 0.03 SBU perl0.39 SBU -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
