howto for jhalfs LFS-devel build ?
Hello. I've spent a couple of ours now tryng to get jhalfs (svn trunk) to build the LFS svn version. But I can't get it done. - I've built by hand a couple of times already (at the time of 6.3 apprx.) - I've googled but couldn't find nothing Is there a step-by-step howto anywhee or would some kind soul be able to give a rough sketch what are the steps which are needed? thx in advance, jens -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [BUG]svn version : wrong download link for the mpfr sources
Emmanuel Trillaud wrote: > In the trunk version SVN-200902017 section 3.2 > The download link for the mpfr lib is wrong : > http://www.mpfr.org/mpfr-current/mpfr-2.4.0.tar.bz2 > SHOULD BE > http://www.mpfr.org/mpfr-current/mpfr-2.4.1.tar.bz2. > 2.4.1 is the last version. ...but if I may say so, http://www.mpfr.org/mpfr-2.4.0/mpfr-2.4.0.tar.bz2 should work... greets, jens -- By caffeine alone I set my mind in motion, By the beans of Java do thoughts acquire speed, hands acquire shaking, the shaking becomes a warning, By caffeine alone do I set my mind in motion -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Ticket #2552 (set MTU size in network scripts)
Hi.
I wanted to write this for a while already, so here it goes:
Like thomas, we had to adjust the MTU for our interfaces;
we do it per default like this in the ipv4 service script:
= patch start
--- lfs/sysconfig/network-devices/services/ipv4-static 2007-10-23
11:15:59.0 +0200
+++ lfs/sysconfig/network-devices/services/ipv4-static 2007-10-23
11:17:13.0 +0200
@@ -13,6 +13,9 @@
#
+
+MTU=1492
+
. /etc/sysconfig/rc
. ${rc_functions}
. ${IFCONFIG}
@@ -23,6 +26,7 @@
exit 1
fi
+
if [ -z "${PREFIX}" -a -z "${PEER}" ]; then
boot_mesg -n "PREFIX variable missing from ${IFCONFIG}," ${WARNING}
boot_mesg " assuming 24."
@@ -48,6 +52,10 @@
boot_mesg "Adding IPv4 address ${IP} to the ${1}
interface..."
ip addr add ${args} dev ${1}
evaluate_retval
+
+ echo "Setting the MTU for $1 to $MTU"
+ echo "$MTU" > "/sys/class/net/$1/mtu"
+ evaluate_retval
if [ -n "${GATEWAY}" ]; then
if ip route | grep -q default; then
= patch end
As the $IFCONFIG file is read after the fixed "MTU=1492, it can be
overridden inside of it.
But something like the attached patch "ipv4-static.diff" would probably
more desirable for the book, as it just modifies the current behavior in
case an MTU setting is present in the $IFCONFIG file.
There has been a script in the
bootscripts/contrib/sysconfig/network-devices/services/mtu file of the
LFS-Book repo, but I find it slightly more aesthetic to just include it
in the ipv4-static script, avoiding for example the "..cannot continue"
message which the seperate script would produce for $IFCONFIGs without
an MTU entry.
I've attached a patch to the (LFS-)book's sources to that effect.
While the the ticket resides in the trac for BLFS, the change would have
to take place in LFS, wouldn't it, so I cc'd the LFS development list.
greets,
jens
--- lfs/sysconfig/network-devices/services/ipv4-static.orig 2009-04-23
17:10:26.0 +0200
+++ lfs/sysconfig/network-devices/services/ipv4-static 2009-04-23
17:13:20.0 +0200
@@ -49,6 +49,12 @@
ip addr add ${args} dev ${1}
evaluate_retval
+ if [ -n "${MTU}" ]; then
+ boot_mesg "Setting the MTU for $1 to $MTU"
+ echo "$MTU" > "/sys/class/net/$1/mtu"
+ evaluate_retval
+ fi
+
if [ -n "${GATEWAY}" ]; then
if ip route | grep -q default; then
boot_mesg "Gateway already setup; skipping."
${WARNING}
Index: bootscripts/contrib/lsb-v3/sysconfig/network-devices/services/ipv4-static
===
--- bootscripts/contrib/lsb-v3/sysconfig/network-devices/services/ipv4-static
(revision 8852)
+++ bootscripts/contrib/lsb-v3/sysconfig/network-devices/services/ipv4-static
(working copy)
@@ -48,6 +48,12 @@
ip addr add ${args} dev ${1}
evaluate_retval
+ if [ -n "${MTU}" ]; then
+ boot_mesg "Setting the MTU for $1 to $MTU"
+ echo "$MTU" > "/sys/class/net/$1/mtu"
+ evaluate_retval
+ fi
+
if [ -n "${GATEWAY}" ]; then
if ip route | grep -q default; then
log_warning_msg "Gateway already setup;
skipping." ${WARNING}
Index: bootscripts/lfs/sysconfig/network-devices/services/ipv4-static
===
--- bootscripts/lfs/sysconfig/network-devices/services/ipv4-static
(revision 8852)
+++ bootscripts/lfs/sysconfig/network-devices/services/ipv4-static
(working copy)
@@ -49,6 +49,12 @@
ip addr add ${args} dev ${1}
evaluate_retval
+ if [ -n "${MTU}" ]; then
+ boot_mesg "Setting the MTU for $1 to $MTU"
+ echo "$MTU" > "/sys/class/net/$1/mtu"
+ evaluate_retval
+ fi
+
if [ -n "${GATEWAY}" ]; then
if ip route | grep -q default; then
boot_mesg "Gateway already setup; skipping."
${WARNING}
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Problem with bash-3.2 patch
On Wed, Mar 14, 2007 at 03:20:05PM -0700, Dan Nicholson wrote: > On 3/14/07, Richard Gill <[EMAIL PROTECTED]> wrote: > > > > In the latest development branch (SVN-20070314), the > > bash-3.2-fixes-2.patch creates a problem in bash, as regular > > expression matches in conditionals don't work anymore : > > > > [[ $test =~ $regexpr ]] > > > > always returns 1 in $?. > > Tested without the patch, all works fine. I saw a 'protection' fix in > > the patch (look for COND_REGEX) ; I guess the problem is there. I > > don't have any fix for the patch for now, and not sure to be able to > > do so. > > There's a new upstream patch that's supposed to fix the regex > operator, but only when " are used. You can at least give that a shot. > The LFS patch includes fixes 001-009. > > http://ftp.gnu.org/gnu/bash/bash-3.2-patches/bash32-010 Reading your posts, I got and applied the above-mentioned patch; contrary to what I expected, [[ $test =~ $regexpr ]] worked, whereas [[ "$test" =~ "$regexpr" ]] did not. See below: = [EMAIL PROTECTED]:/usr/src/rpm> if [[ "sploerp" =~ "s.*rp" ]] ; then echo yes ; fi [EMAIL PROTECTED]:/usr/src/rpm> if [[ sploerp =~ s.*rp ]] ; then echo yes ; fi yes = greets, Jens -- [EMAIL PROTECTED] 23.56...drifting By caffeine alone I set my mind in motion, By the beans of Java do thoughts acquire speed, hands acquire shaking, the shaking becomes a warning, By caffeine alone do I set my mind in motion -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Problem with bash-3.2 patch
On Thu, Mar 15, 2007 at 01:11:31PM +0100, Jens Stroebel wrote: > Reading your posts, I got and applied the above-mentioned patch; > contrary to what I expected, [[ $test =~ $regexpr ]] worked, whereas > [[ "$test" =~ "$regexpr" ]] did not. See below: > > = > [EMAIL PROTECTED]:/usr/src/rpm> if [[ "sploerp" =~ "s.*rp" ]] ; then echo yes > ; fi > [EMAIL PROTECTED]:/usr/src/rpm> if [[ sploerp =~ s.*rp ]] ; then echo yes ; fi > yes > = Following up my own post, sorry, but I thought the above incomplete after a bit more testing: It seems like it's OK to "" the left side of the comparison, but not the regex which should be matched: = [EMAIL PROTECTED]:~/make> if [[ "sploerp" =~ s.*rp ]] ; then echo yes ; fi yes = If the regex-pattern is ill-suited to be matched without somehow "enclosing" it, round brackets seem to work fine (which is to be expected, but I thought I'd mention it anyway...) = [EMAIL PROTECTED]:~/make> if [[ "sploerp" =~ s[ ]*.*rp ]] ; then echo yes ; fi bash: syntax error in conditional expression bash: syntax error near `]*.*rp' [EMAIL PROTECTED]:~/make> if [[ "sploerp" =~ (s[ ]*.*rp) ]] ; then echo yes ; fi yes = greets, Jens -- [EMAIL PROTECTED] 23.56...drifting By caffeine alone I set my mind in motion, By the beans of Java do thoughts acquire speed, hands acquire shaking, the shaking becomes a warning, By caffeine alone do I set my mind in motion -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Problem with bash-3.2 patch
On Thu, Mar 15, 2007 at 01:12:11PM -0700, Dan Nicholson wrote: [..snip...] > > Following up my own post, sorry, but I thought the above incomplete after > > a bit more testing: > > > > It seems like it's OK to "" the left side of the comparison, > > but not the regex which should be matched: > > Jens, if you think this is a bug, it would be great if you could ask > on bug-bash. The worst that can happen is that they tell you it's not > a bug. Actually, it looks like this has happened already, and you have > to be careful with bash-3.1 v. 3.2 when using quotes on the rhs. I have to admit I'm not sure if it's a bug, really. It seems to me like it's kind of intentional behaviour, given the thread which contains the message w. URL you sent: > http://lists.gnu.org/archive/html/bug-bash/2007-03/msg00017.html Messages http://lists.gnu.org/archive/html/bug-bash/2007-03/msg00037.html and http://lists.gnu.org/archive/html/bug-bash/2007-03/msg00043.html of this thread seem to indicate that the bash people are more concerned about "clearly defined quoting behaviour" than they are about consistent behaviour w. regards to former bash versions. Of course it's inconsistent with former bash-versions and "not nice" for the existing script material, I'd guess. (When regular expressions are seen approaching on the horizon, I normally turn to perl, though...; so it's not an actual problem in our context) I'll try to get something written when I found out how to put an argument against "we finally cleansed it up"... greets, Jens -- [EMAIL PROTECTED] 23.56...drifting With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. [RFC1925 - section 2, subsection 3] -- [EMAIL PROTECTED] 23.56...drifting It hurts sometimes more than we can bear. If we could live without passion, maybe we'd know some kind of peace. But we would be hollow. Empty rooms, shuttered and dank... Without passion, we'd be truly dead. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
thunderbird + firefox: 1.5.0.9 -> 1.5.0.10 (system_nss patch)
Hi out there. Due to the mozilla security announcements ( http://www.mozilla.org/security/announce/ ) concerning versions 1.5.0.9, I was inclined to upgrade both to 1.5.0.10. I had to recognize that, while the pago-patch from BLFS still applies, the system_nss patch didn't like to do so. (Upgraded nss to 3.11.5 [ ftp://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_11_5_RTM/src/nss-3.11.5-with-nspr-4.6.5.tar.gz ] , too, by the way) I massaged the patches (for firefox as well as for thunderbird) to apply again, but I am not in a position to judge if I "did it right", apart from both now applying and both apps compiling and running afterwards. If the actual maintainer of these patches might take a look at them and correcting eventual errors, the build instructions in the BLFS(-devel) would apply to (firefox-|thunderbird-)1.5.0.10 with working results, as far as I could see (changing the version-numbers as they appear explicitely would, of course, also be needed). You'll find the two changed patches attached to this message. Greets, Jens -- [EMAIL PROTECTED] 23.56...drifting By caffeine alone I set my mind in motion, By the beans of Java do thoughts acquire speed, hands acquire shaking, the shaking becomes a warning, By caffeine alone do I set my mind in motion Submitted By:Randy McMurchy Date:2006-01-20 Initial Package Version: 1.5 Upstream Status: In trunk and firefox-2.0 branch. Origin: https://bugzilla.mozilla.org/show_bug.cgi?id=255408 Description: Fixes the --use-system-nss and --with-nss-prefix switches so that they actually work. This patch allows the Mozilla products to use the system installed versions of NSS and NSPR. diff -Naur mozilla-orig/aclocal.m4 mozilla/aclocal.m4 --- mozilla-orig/aclocal.m4 2004-05-13 03:12:47.0 + +++ mozilla/aclocal.m4 2006-01-21 00:57:48.0 + @@ -8,6 +8,7 @@ builtin(include, build/autoconf/libIDL.m4)dnl builtin(include, build/autoconf/libIDL-2.m4)dnl builtin(include, build/autoconf/nspr.m4)dnl +builtin(include, build/autoconf/nss.m4)dnl builtin(include, build/autoconf/libart.m4)dnl builtin(include, build/autoconf/pkg.m4)dnl builtin(include, build/autoconf/freetype2.m4)dnl diff -Naur mozilla-orig/build/autoconf/nss.m4 mozilla/build/autoconf/nss.m4 --- mozilla-orig/build/autoconf/nss.m4 1970-01-01 00:00:00.0 + +++ mozilla/build/autoconf/nss.m4 2006-01-21 00:57:48.0 + @@ -0,0 +1,67 @@ +# -*- tab-width: 4; -*- +# Configure paths for NSS +# Public domain - Chris Seawood <[EMAIL PROTECTED]> 2001-04-05 +# Based upon gtk.m4 (also PD) by Owen Taylor + +dnl AM_PATH_NSS([MINIMUM-VERSION, [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]]]) +dnl Test for NSS, and define NSS_CFLAGS and NSS_LIBS +AC_DEFUN(AM_PATH_NSS, +[dnl + +AC_ARG_WITH(nss-prefix, + [ --with-nss-prefix=PFX Prefix where NSS is installed], + nss_config_prefix="$withval", + nss_config_prefix="") + +AC_ARG_WITH(nss-exec-prefix, + [ --with-nss-exec-prefix=PFX + Exec prefix where NSS is installed], + nss_config_exec_prefix="$withval", + nss_config_exec_prefix="") + + if test -n "$nss_config_exec_prefix"; then + nss_config_args="$nss_config_args --exec-prefix=$nss_config_exec_prefix" + if test -z "$NSS_CONFIG"; then + NSS_CONFIG=$nss_config_exec_prefix/bin/nss-config + fi + fi + if test -n "$nss_config_prefix"; then + nss_config_args="$nss_config_args --prefix=$nss_config_prefix" + if test -z "$NSS_CONFIG"; then + NSS_CONFIG=$nss_config_prefix/bin/nss-config + fi + fi + + unset ac_cv_path_NSS_CONFIG + AC_PATH_PROG(NSS_CONFIG, nss-config, no) + min_nss_version=ifelse([$1], ,3.0.0,$1) + AC_MSG_CHECKING(for NSS - version >= $min_nss_version (skipping)) + + no_nss="" + if test "$NSS_CONFIG" = "no"; then + no_nss="yes" + else + NSS_CFLAGS=`$NSS_CONFIG $nss_config_args --cflags` + NSS_LIBS=`$NSS_CONFIG $nss_config_args --libs` + + dnl Skip version check for now + nss_config_major_version=`$NSS_CONFIG $nss_config_args --version | \ + sed 's/\([[0-9]]*\).\([[0-9]]*\).\([[0-9]]*\)/\1/'` + nss_config_minor_version=`$NSS_CONFIG $nss_config_args --version | \ + sed 's/\([[0-9]]*\).\([[0-9]]*\).\([[0-9]]*\)/\2/'` + nss_config_micro_version=`$NSS_CONFIG $nss_config_args --version | \ + sed 's/\([[0-9]]*\).\([[0-9]]*\).\([[0-9]]*\)/\3/'` + fi + + if test -z "$no_nss"; then + AC_MSG_RESULT(
download location for shadow down since a while ?
Hello. I've been trying for some time now to get the shadow-4.0.18.1 source from ftp://ftp.pld.org.pl/software/shadow/shadow-4.0.18.1.tar.bz2 ; the site is not resolvable, though. ( ping ftp.pld.org.pl ping: unknown host ftp.pld.org.pl host ftp.pld.org.pl Host ftp.pld.org.pl not found: 3(NXDOMAIN) ) Is anything known about that? greets, Jens -- [EMAIL PROTECTED] 23.56...drifting By caffeine alone I set my mind in motion, By the beans of Java do thoughts acquire speed, hands acquire shaking, the shaking becomes a warning, By caffeine alone do I set my mind in motion -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
URL to vim-7.1-mandir-1.patch not accessible under URL from LFS devel book?
Hello again; While keeping track with the changes in the LFS devel book, I came across the vim-7.0 -> 7.1 update. The patch-list at http://www.linuxfromscratch.org/lfs/view/development/chapter03/patches.html references the URL for the mandir-patch: http://www.linuxfromscratch.org/patches/lfs/development/vim-7.1-mandir-1.patch but it is not (yet?) available under said URL. greets, Jens -- [EMAIL PROTECTED] 23.56...drifting By caffeine alone I set my mind in motion, By the beans of Java do thoughts acquire speed, hands acquire shaking, the shaking becomes a warning, By caffeine alone do I set my mind in motion -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: download location for shadow down since a while ?
Dan Nicholson wrote: > Yeah, that's about the least reliable server on the internet :) You > can just use a mirror for now. > > http://anduin.linuxfromscratch.org/sources/LFS/lfs-packages/development/shadow-4.0.18.1.tar.bz2 Thanks for the link. New version now already integrated in the packages we use here. greets, Jens -- [EMAIL PROTECTED] 23.56...drifting By caffeine alone I set my mind in motion, By the beans of Java do thoughts acquire speed, hands acquire shaking, the shaking becomes a warning, By caffeine alone do I set my mind in motion -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
samba vulnerability, new version 3.0.25
Hiya. In the daily routine of running over vulnerability reports, I encountered a samba vulnerability report I thouht I'd mention here: http://www.securityfocus.com/bid/23972 and, corresponding, the release announcement at http://news.samba.org/ greets, Jens -- [EMAIL PROTECTED] 23.56...drifting By caffeine alone I set my mind in motion, By the beans of Java do thoughts acquire speed, hands acquire shaking, the shaking becomes a warning, By caffeine alone do I set my mind in motion -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
udev-110 ->111 changed behaviour for naming net-devices?
Hello. I tried to follow the LFS-devel book on udev but ran into the following: Setup: - kernel 2.6.21 - udev-111 - 2 network cards; one builtin (broadcomm, using tg3), one connected via pcmcia (using 8139too) - first network card is assigned name eth0 via udev-rule ACTION=="add", SUBSYSTEM=="net", BUS=="pci", ID==":02:00.0", \ NAME="eth0" While with udev-110, the cards got named eth0 and eth1, with udev-111, the second card gets eth1 at recognition (bootlog) but in the course of affairs gets renamed to eth1_rename. This prevents the usual network setup from happening correctly, as the scripts would like to assign address to eth1. I am aware that I could force eth1 onto the device with an udev-rule like the above for eth0, but would like to avoid this if at all possible. Has anybody here any information about why the behaviour of udev could have changed in this way? (did look into the rules distributed under etc/udev/rules.d/, but it seems only a script concerning storage [60-persistent-storage.rules] has changed between 110+111...) greets, Jens -- [EMAIL PROTECTED] 23.56...drifting By caffeine alone I set my mind in motion, By the beans of Java do thoughts acquire speed, hands acquire shaking, the shaking becomes a warning, By caffeine alone do I set my mind in motion -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: udev-110 ->111 changed behaviour for naming net-devices?
On Mon, May 21, 2007 at 06:22:07PM -0400, Bryan Kadzban wrote: > But if you remove all your rules and reboot, udev will generate new > rules for all your NICs, so Alexander's suggestion of removing them all > is a good idea. Just beware that what you want isn't possible. > > (Why do you want it, by the way?) That's because we install a laptop with a pcmcia-plugged network card. Should someone at a later time change this card (e.g. it is defect), the MAC would change, too. This would lead to the pcmcia network card not getting the name the vanished card had, in spite of being in the same place and having to fulfill the same tasks (which it won't, because it'd have another name and the network configs wouldn't match anymore). Would we use the laptop for ourselves only, it would be OK to be forced to e.g. erase the persistent-net.rules script. But this is not the case. So the NIC in the PCMCIA slot should "just work" as eth1. greets, Jens -- [EMAIL PROTECTED] 23.56...drifting It hurts sometimes more than we can bear. If we could live without passion, maybe we'd know some kind of peace. But we would be hollow. Empty rooms, shuttered and dank... Without passion, we'd be truly dead. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: udev-110 ->111 changed behaviour for naming net-devices?
Bryan Kadzban wrote: > On Tue, May 22, 2007 at 06:03:39PM +0200, Jens Stroebel wrote: >> On Mon, May 21, 2007 at 06:22:07PM -0400, Bryan Kadzban wrote: >> >>> (Why do you want it, by the way?) >> That's because we install a laptop with a pcmcia-plugged network card. >> Should someone at a later time change this card (e.g. it is defect), >> the MAC would change, too. > > Ah. > > Would it work to use by-path persistence? That's not supported in the > book or by the udev developers because (e.g.) USB devices change their > paths way too often. But if these laptops only have one PCMCIA slot, > then that might work. Having tried the below-mentioned patch, I'd say this should pose no problems. The location of the PCMCIA slot (id-wise) shouldn't change as far as I understand; and yes, it only has one of them. As long as nothing changes with regard to the sys filesystem, we should be OK with these rules even in case of a NIC replacement. The patch applied cleanly on udev-110 + udev-111 (although I did only test it running on udev-110 - works fine there). > I had a preliminary by-path patch for udev somewhere, let me see if I > can find it... Ah: > > http://marc.info/?l=linux-hotplug-devel&m=117141213806593&w=2 > > however, reading it again, I said that I didn't think it'd work with > PCMCIA devices. I cannot second this. By observation, it seems that the NICs we use in the PCMCIA slot appear to the kernel as a PCI device. lspci for the card in PCMCIA slot: 04:00.0 Ethernet controller: Abocom Systems Inc RTL8139 [FE2000VX] CardBus Fast Ethernet Attached Port Adapter (rev 10) I don't know about "all NICs plugged to PCMCIA slots", but the ones we use(d) all behave(d) that way. > If I knew how those devices showed up in sysfs, I could > probably add it (otherwise you could just treat this patch as a starting > point). Regarding the extension towards PCMCIA-slotted NICs, I can give you no interesting information, as it works right without any changes in our case. There isn't even an entry under /sys/bus/pcmcia on the laptop. greets, Jens PS: thx for the patch, fine thing, that -- [EMAIL PROTECTED] 23.56...drifting By caffeine alone I set my mind in motion, By the beans of Java do thoughts acquire speed, hands acquire shaking, the shaking becomes a warning, By caffeine alone do I set my mind in motion -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: udev-110 ->111 changed behaviour for naming net-devices?
Bryan Kadzban wrote: > Hmm. I figured they'd show up on a different bus, since it is really a > different physical bus. Well, whatever. I'd still like to know where > the device symlink points though. :-) I'm not sure which one... you mean like: ls -l /sys/class/net/eth1/device = lrwxrwxrwx 1 root root 0 2007-05-23 10:56 /sys/class/net/eth1/device -> ../../../devices/pci:00/:00:1e.0/:03:01.0/:04:00.0 = ? greets, Jens -- [EMAIL PROTECTED] 23.56...drifting By caffeine alone I set my mind in motion, By the beans of Java do thoughts acquire speed, hands acquire shaking, the shaking becomes a warning, By caffeine alone do I set my mind in motion -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: udev-110 ->111 changed behaviour for naming net-devices?
Bryan Kadzban wrote:
> I'd like to see the results of:
> grep -H . \
> /sys/devices/pci\:00/\:00\:1e.0/:03:01.0/:04:00.0/{,subsystem_}{vendor,device}
/sys/devices/pci:00/:00:1e.0/:03:01.0/:04:00.0/vendor:0x13d1
/sys/devices/pci:00/:00:1e.0/:03:01.0/:04:00.0/device:0xab06
/sys/devices/pci:00/:00:1e.0/:03:01.0/:04:00.0/subsystem_vendor:0x13d1
/sys/devices/pci:00/:00:1e.0/:03:01.0/:04:00.0/subsystem_device:0xab06
> grep -H . \
> /sys/devices/pci\:00/\:00\:1e.0/:03:01.0/{,subsystem_}{vendor,device}
/sys/devices/pci:00/:00:1e.0/:03:01.0/vendor:0x1217
/sys/devices/pci:00/:00:1e.0/:03:01.0/device:0x7135
/sys/devices/pci:00/:00:1e.0/:03:01.0/subsystem_vendor:0x1028
/sys/devices/pci:00/:00:1e.0/:03:01.0/subsystem_device:0x01cc
> grep -H . \
> /sys/devices/pci\:00/\:00\:1e.0/{,subsystem_}{vendor,device}
/sys/devices/pci:00/:00:1e.0/vendor:0x8086
/sys/devices/pci:00/:00:1e.0/device:0x2448
/sys/devices/pci:00/:00:1e.0/subsystem_vendor:0x
/sys/devices/pci:00/:00:1e.0/subsystem_device:0x
[...snip...]
> Thanks!
My pleasure.
greets,
Jens
--
[EMAIL PROTECTED]
23.56...drifting
By caffeine alone I set my mind in motion, By the beans of Java
do thoughts acquire speed, hands acquire shaking, the shaking
becomes a warning, By caffeine alone do I set my mind in motion
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
problem description revised [was: Re: udev-110 ->111 changed behaviour for naming net-devices?]
Jens Stroebel wrote: > On Mon, May 21, 2007 at 06:22:07PM -0400, Bryan Kadzban wrote: > >> But if you remove all your rules and reboot, udev will generate new >> rules for all your NICs, so Alexander's suggestion of removing them all >> is a good idea. Just beware that what you want isn't possible. >> >> (Why do you want it, by the way?) > > That's because we install a laptop with a pcmcia-plugged network card. > Should someone at a later time change this card (e.g. it is defect), > the MAC would change, too. > > This would lead to the pcmcia network card not getting the name the > vanished card had, in spite of being in the same place and having to > fulfill the same tasks (which it won't, because it'd have another name > and the network configs wouldn't match anymore). First of all: The observed behavior is (unfortunately) not dependent on udev-111 <-> udev-110. We have seen this behavior more often, lately, still trying to live without persistent, auto-generated network rules. Maybe we'll have to refrain from that, but still udev's naming behavior puzzles me a bit: We have card a -> eth0 (custom rule via PCI-id) card b -> eth1 (should become that automatically, pcmcia-slotted) In the normal boot process (over 50% of the time... *sigh* ..), card a is found first and becomes eth0 straight away-> no problem; card b gets found second and becomes eth1. Problems arise when card b is found first, because: card b becomes eth0 our custom rule wants to assign card a -> eth0 card b gets moved out of the way; because card a is still eth1, card b becomes eth1_rename. card a becomes eth0; but card b stays eth1_rename Shouldn't the final step (eth1_rename -> eth1) be done somehow by something? Is this indeed expected behavior? greets, Jens -- [EMAIL PROTECTED] 23.56...drifting By caffeine alone I set my mind in motion, By the beans of Java do thoughts acquire speed, hands acquire shaking, the shaking becomes a warning, By caffeine alone do I set my mind in motion -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-Bootscripts 20070730
Dan Nicholson wrote: > I rolled a new snapshot that has a few changes since the last 20070420 > tarball. Please test it out so we can get any fixes in to 6.3. They > should be entirely backwards compatible with existing scripts. Hiya. I maybe should know where to look, but I don't... Where is the download location for the new LFS-bootscripts you rolled? greets, jens -- [EMAIL PROTECTED] 23.56...drifting By caffeine alone I set my mind in motion, By the beans of Java do thoughts acquire speed, hands acquire shaking, the shaking becomes a warning, By caffeine alone do I set my mind in motion -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-Bootscripts 20070730
On Mon, Jul 30, 2007 at 02:48:03PM -0700, Dan Nicholson wrote: > I rolled a new snapshot that has a few changes since the last 20070420 > tarball. Please test it out so we can get any fixes in to 6.3. They > should be entirely backwards compatible with existing scripts. On Tue, Jul 31, 2007 at 12:24:54PM +, DJ Lucas wrote: > Jens Stroebel wrote: > > I maybe should know where to look, but I don't... > > Where is the download location for the new LFS-bootscripts you rolled? > > > http://downloads.linuxfromscratch.org/lfs-bootscripts-20070730.tar.bz2 > > -- DJ Lucas Thanks for the URL; as far as I can tell, everything boots flawlessly; there is one thing I did leave out because of local "deviation from the book": we took care to have our loglevel set here before that got into the lfs-bootscripts package, so I didn't check that it behaves like planned via an entry in /etc/sysconfig/console. Everything else seems to be perfectly happy with the new boot scripts, including the bootscripts which derive from blfs packages (they do use the functions of lfs bootscripts, right?). greets, jens -- [EMAIL PROTECTED] 23.56...drifting ``The lyf so short, the craft so long to lerne.'' - Chaucer pgp7tCgXiu5EE.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
MTU manipulation through lfs-bootscripts: has it been deprecated?
Hello beautiful people :) I was in a situation which prompted (unfortunately) for lowering the MTU of a network-device to assure functionality as planned (r8169 driver, 8168B/8111 NIC) While looking at the actual bootscripts and searching a bit/asking my way around, I came across http://wiki.linuxfromscratch.org/lfs/browser/trunk/bootscripts/contrib/sysconfig/network-devices/services/mtu?rev=4187 which is a service script allowing one to set the MTU of a network device via the same mechanism which sets it up at boot-time. As this script is (no longer?) part of the LFS-bootscripts, I was asking myself why this is the case...? Any insight appreciated, no hurry nescessary (I "had to" re-include it already..). greets, jens -- [EMAIL PROTECTED] 23.56...drifting By caffeine alone I set my mind in motion, By the beans of Java do thoughts acquire speed, hands acquire shaking, the shaking becomes a warning, By caffeine alone do I set my mind in motion -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
e2fsprogs-1.40.{5,6} + grub-0.97
Hi there.
When updating to e2fsprogs-1.40.6 like LFS devel did, I noticed my
system(s) no longer booting via grub. Slightly inconvenient ;-)
After digging around a while I found that mke2fs has changed the inode
size to 256, making grub effectively unable to read the filesystem to
find it's directory, the kernel etc.
I dug around in the net for a while and found a patch
(
http://people.debian.org/~terpstra/message/20080130.140155.866d3ad1.en.html
)
but the formatting on a html-page always leaves a bit to be desired.
I attach the version we use her for review, eventually it can be of use
for LFS devel.
Warmest greetings, keep up the good work,
drifter
--
[EMAIL PROTECTED]
23.56...drifting
By caffeine alone I set my mind in motion, By the beans of Java
do thoughts acquire speed, hands acquire shaking, the shaking
becomes a warning, By caffeine alone do I set my mind in motion
--- stage2/fsys_ext2fs.c.unchanged 2008-02-22 15:45:07.0 +0100
+++ stage2/fsys_ext2fs.c2008-02-22 15:46:25.0 +0100
@@ -79,7 +79,52 @@
__u32 s_rev_level; /* Revision level */
__u16 s_def_resuid;/* Default uid for reserved blocks */
__u16 s_def_resgid;/* Default gid for reserved blocks */
-__u32 s_reserved[235]; /* Padding to the end of the block */
+ /*
+ * These fields are for EXT2_DYNAMIC_REV superblocks only.
+ *
+ * Note: the difference between the compatible feature set and
+ * the incompatible feature set is that if there is a bit set
+ * in the incompatible feature set that the kernel doesn't
+ * know about, it should refuse to mount the filesystem.
+ *
+ * e2fsck's requirements are more strict; if it doesn't know
+ * about a feature in either the compatible or incompatible
+ * feature set, it must abort and not try to meddle with
+ * things it doesn't understand...
+ */
+__u32 s_first_ino;/* First non-reserved inode */
+__u16 s_inode_size;/* size of inode structure */
+__u16 s_block_group_nr;/* block group # of this superblock */
+__u32 s_feature_compat;/* compatible feature set */
+__u32 s_feature_incompat;/* incompatible feature set */
+__u32 s_feature_ro_compat;/* readonly-compatible feature set */
+__u8 s_uuid[16];/* 128-bit uuid for volume */
+ char s_volume_name[16];/* volume name */
+ char s_last_mounted[64];/* directory where last mounted */
+__u32 s_algorithm_usage_bitmap; /* For compression */
+ /*
+ * Performance hints. Directory preallocation should only
+ * happen if the EXT2_FEATURE_COMPAT_DIR_PREALLOC flag is on.
+ */
+__u8 s_prealloc_blocks;/* Nr of blocks to try to preallocate*/
+__u8 s_prealloc_dir_blocks;/* Nr to preallocate for dirs */
+__u16 s_reserved_gdt_blocks;/* Per group table for online growth */
+ /*
+ * Journaling support valid if EXT2_FEATURE_COMPAT_HAS_JOURNAL set.
+ */
+__u8 s_journal_uuid[16];/* uuid of journal superblock */
+__u32 s_journal_inum;/* inode number of journal file */
+__u32 s_journal_dev;/* device number of journal file */
+__u32 s_last_orphan;/* start of list of inodes to delete */
+__u32 s_hash_seed[4];/* HTREE hash seed */
+__u8 s_def_hash_version;/* Default hash version to use */
+__u8 s_jnl_backup_type; /* Default type of journal backup */
+__u16 s_reserved_word_pad;
+__u32 s_default_mount_opts;
+__u32 s_first_meta_bg;/* First metablock group */
+__u32 s_mkfs_time;/* When the filesystem was created */
+__u32 s_jnl_blocks[17]; /* Backup of the journal inode */
+__u32 s_reserved[172];/* Padding to the end of the block */
};
struct ext2_group_desc
@@ -218,6 +263,10 @@
#define EXT2_ADDR_PER_BLOCK(s) (EXT2_BLOCK_SIZE(s) / sizeof (__u32))
#define EXT2_ADDR_PER_BLOCK_BITS(s)(log2(EXT2_ADDR_PER_BLOCK(s)))
+#define EXT2_INODE_SIZE(s)(SUPERBLOCK->s_inode_size)
+#define EXT2_INODES_PER_BLOCK(s)(EXT2_BLOCK_SIZE(s)/EXT2_INODE_SIZE(s))
+
+
/* linux/ext2_fs.h */
#define EXT2_BLOCK_SIZE_BITS(s)((s)->s_log_block_size + 10)
/* kind of from ext2/super.c */
@@ -553,7 +602,7 @@
gdp = GROUP_DESC;
ino_blk = gdp[desc].bg_inode_table +
(((current_ino - 1) % (SUPERBLOCK->s_inodes_per_group))
->> log2 (EXT2_BLOCK_SIZE (SUPERBLOCK) / sizeof (struct ext2_inode)));
+ >> log2 (EXT2_INODES_PER_BLOCK (SUPERBLOCK)));
#ifdef E2DEBUG
printf ("inode table fsblock=%d\n", ino_blk);
#endif /* E2DEBUG */
@@ -565,13 +614,14 @@
/* reset indirect blocks! */
mapblock2 = mapblock1 = -1;
- raw_inode = INODE +
- ((current_ino - 1)
-& (EXT2_BLOCK_SIZE (SUPERBLOCK) / sizeof (struct ext2_inode) - 1));
+ raw_inode = (struct ext2_inode *)((char *)INODE +
+((current_ino - 1) & (EXT2_INODES_PER_BLOCK (SUPERB
patch for grub-0.97 [was: Re: Choosing a boot loader for LFS 7.0]
Alexander E. Patrakov wrote: Hello, as explained in http://wiki.linuxfromscratch.org/lfs/ticket/2161 (a blocker), due to recent changes in e2fsprogs, Grub-0.97 no longer works (cannot read any files from the resulting filesystem, cannot be installed into MBR, and the book is thus horribly broken). There are a couple of tickets about alternative boot loaders: http://wiki.linuxfromscratch.org/lfs/ticket/2093: just a proposal to add a new section about boot loaders; http://wiki.linuxfromscratch.org/lfs/ticket/1955: duplicate, but with more discussion. Did anyone investigate the boot loader options further? What should be done for LFS-7.0? And before anyone objects to LILO on the basis that you must not forget to run it: write the /sbin/installkernel script and run "make install" in the kernel tree (it calls /sbin/installkernel, that should rename and install bzImage and update the boot loader), and the problem of forgetting to run lilo will go away. As mentioned in another mail to this list (MsgID: <[EMAIL PROTECTED]> ), there already exists a patch to meke "old" grub working, although I don't know if that's the way LFS wants to go... Anyway, I'm attaching it here, again. (patch originally found at: http://people.debian.org/~terpstra/message/20080130.140155.866d3ad1.en.html and re-formatted to apply, works here ...) greets, jens -- [EMAIL PROTECTED] 23.56...drifting By caffeine alone I set my mind in motion, By the beans of Java do thoughts acquire speed, hands acquire shaking, the shaking becomes a warning, By caffeine alone do I set my mind in motion --- stage2/fsys_ext2fs.c.unchanged 2008-02-22 15:45:07.0 +0100 +++ stage2/fsys_ext2fs.c2008-02-22 15:46:25.0 +0100 @@ -79,7 +79,52 @@ __u32 s_rev_level; /* Revision level */ __u16 s_def_resuid;/* Default uid for reserved blocks */ __u16 s_def_resgid;/* Default gid for reserved blocks */ -__u32 s_reserved[235]; /* Padding to the end of the block */ + /* + * These fields are for EXT2_DYNAMIC_REV superblocks only. + * + * Note: the difference between the compatible feature set and + * the incompatible feature set is that if there is a bit set + * in the incompatible feature set that the kernel doesn't + * know about, it should refuse to mount the filesystem. + * + * e2fsck's requirements are more strict; if it doesn't know + * about a feature in either the compatible or incompatible + * feature set, it must abort and not try to meddle with + * things it doesn't understand... + */ +__u32 s_first_ino;/* First non-reserved inode */ +__u16 s_inode_size;/* size of inode structure */ +__u16 s_block_group_nr;/* block group # of this superblock */ +__u32 s_feature_compat;/* compatible feature set */ +__u32 s_feature_incompat;/* incompatible feature set */ +__u32 s_feature_ro_compat;/* readonly-compatible feature set */ +__u8 s_uuid[16];/* 128-bit uuid for volume */ + char s_volume_name[16];/* volume name */ + char s_last_mounted[64];/* directory where last mounted */ +__u32 s_algorithm_usage_bitmap; /* For compression */ + /* + * Performance hints. Directory preallocation should only + * happen if the EXT2_FEATURE_COMPAT_DIR_PREALLOC flag is on. + */ +__u8 s_prealloc_blocks;/* Nr of blocks to try to preallocate*/ +__u8 s_prealloc_dir_blocks;/* Nr to preallocate for dirs */ +__u16 s_reserved_gdt_blocks;/* Per group table for online growth */ + /* + * Journaling support valid if EXT2_FEATURE_COMPAT_HAS_JOURNAL set. + */ +__u8 s_journal_uuid[16];/* uuid of journal superblock */ +__u32 s_journal_inum;/* inode number of journal file */ +__u32 s_journal_dev;/* device number of journal file */ +__u32 s_last_orphan;/* start of list of inodes to delete */ +__u32 s_hash_seed[4];/* HTREE hash seed */ +__u8 s_def_hash_version;/* Default hash version to use */ +__u8 s_jnl_backup_type; /* Default type of journal backup */ +__u16 s_reserved_word_pad; +__u32 s_default_mount_opts; +__u32 s_first_meta_bg;/* First metablock group */ +__u32 s_mkfs_time;/* When the filesystem was created */ +__u32 s_jnl_blocks[17]; /* Backup of the journal inode */ +__u32 s_reserved[172];/* Padding to the end of the block */ }; struct ext2_group_desc @@ -218,6 +263,10 @@ #define EXT2_ADDR_PER_BLOCK(s) (EXT2_BLOCK_SIZE(s) / sizeof (__u32)) #define EXT2_ADDR_PER_BLOCK_BITS(s)(log2(EXT2_ADDR_PER_BLOCK(s))) +#define EXT2_INODE_SIZE(s)(SUPERBLOCK->s_inode_size) +#define EXT2_INODES_PER_BLOCK(s)(EXT2_BLOCK_SIZE(s)/EXT2_INODE_SIZE(s)) + + /* linux/ext2_fs.h */ #define EXT2_BLOCK_SIZE_BITS(s)((s)->s_log_block_size + 10) /* kind of from ext2/super.c */ @@ -553,7 +602,7 @@ gdp = GROUP
berkeley-db - db-2.8.1-fixes-1.patch not present
Hello. While browsing the wget list generated for the LFS devel book, I noticed that http://www.linuxfromscratch.org/patches/lfs/development/db-2.8.1-fixes-1.patch is not present... greets, jens -- [EMAIL PROTECTED] 23.56...drifting By caffeine alone I set my mind in motion, By the beans of Java do thoughts acquire speed, hands acquire shaking, the shaking becomes a warning, By caffeine alone do I set my mind in motion -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: initd-tools-0.1.1
Dan Nicholson wrote: Hiya. > It mostly seems to be working, but there is still a bug in the > Should-Stop code as well as many other bugs that probably have not > been uncovered in my limited testing. Please use with caution and > backup your /etc/init.d and /etc/rc*.d directories before using > install_initd and remove_initd. The layout of LFS bootscripts right now seems to be that the init.d- and rc*.d-directories live under /etc/rc.d. Will this change (maybe because of LSB) in the future? greets, jens -- By caffeine alone I set my mind in motion, By the beans of Java do thoughts acquire speed, hands acquire shaking, the shaking becomes a warning, By caffeine alone do I set my mind in motion -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
