Re: Incompatibility of udev and /usr
On Wed, 2011-04-13 at 21:04 -0500, 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. 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 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 Simon. signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Kernel options help
To list, I built a new LFS 6.8 and everything is kosher save for some slowness. I built an x86_64 kernel (2.6.38.2) all on a Xen host (5.6.100) on a Quad Proc Xeon. It boots with no issues until I try to configure a package. As an example, if I run the ./configure for the openssh package, it takes around 5 min just to configure. Making with -j4 tends to go well but still not as fast as I think it could. It shouldn't be a Xen issue as my LFS build system was the LFS live CD. Configuring under the liveCD proceeded at a normal rate. I've tried a few different kernel options but none seem to make any difference. Any help would be appreciated. -- 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
Simon Geard wrote: [...] 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. Well, I also have read this argument, and it cuts no water with me. 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 Interesting. I was unaware of that. Thanks! Mike -- p=p=%c%s%c;main(){printf(p,34,p,34);};main(){printf(p,34,p,34);} Oppose globalization and One World Governments like the UN. This message made from 100% recycled bits. You have found the bank of Larn. I speak only for myself, and I am unanimous in that! -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Kernel options help
On Thu, Apr 14, 2011 at 08:13:06AM -0600, Dave Hajoglou wrote: To list, I built a new LFS 6.8 and everything is kosher save for some slowness. I built an x86_64 kernel (2.6.38.2) all on a Xen host (5.6.100) on a Quad Proc Xeon. It boots with no issues until I try to configure a package. As an example, if I run the ./configure for the openssh package, it takes around 5 min just to configure. Making with -j4 tends to go well but still not as fast as I think it could. It shouldn't be a Xen issue as my LFS build system was the LFS live CD. Configuring under the liveCD proceeded at a normal rate. I've tried a few different kernel options but none seem to make any difference. Any help would be appreciated. I wouldn't expect the kernel config to make a lot of difference. The whole system is 64-bit ? It rather sounds like you might have masses of memory on a 32-bit system, and all the time is taken up in bounce-buffers (to address more than 4GB). 'top' might help - while configure is running, to see what where the cycles are being spent - a lot of time in wait might imply a disk or filesystem problem. Or, perhaps there is a lot of background activity. Maybe it's a question of configuring xen differently, e.g. pinning a cpu core (I see that mentioned in the Arch wiki, but I've no idea how to do it). ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Kernel options help
Dave Hajoglou wrote: On Thu, Apr 14, 2011 at 8:13 AM, Dave Hajoglou dhajog...@gmail.com wrote: To list, I built a new LFS 6.8 and everything is kosher save for some slowness. I built an x86_64 kernel (2.6.38.2) all on a Xen host (5.6.100) on a Quad Proc Xeon. It boots with no issues until I try to configure a package. As an example, if I run the ./configure for the openssh package, it takes around 5 min just to configure. Looks more like around 34 min to configure. # time ./configure...: real34m19.631s user0m22.352s sys 36m1.760s # time make -j4 real1m27.764s user0m37.722s sys 5m3.909s There is definitely something wrong. On a production LFS system running in a virtual envronment, I get: real0m18.514s user0m8.984s sys 0m2.697s cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 6 model name : QEMU Virtual CPU version 0.9.1 stepping: 3 cpu MHz : 2260.701 cache size : 32 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 4 wp : yes flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm pni hypervisor bogomips: 4521.40 clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: I'm not sure why you want multiple CPUs in a virtual environment when you can clone a new one for each task. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page