Version 7.0-cross-lfs-20051023-x86_64
Hi all,
Just build the boot stages of Version 7.0-cross-lfs-20051023-x86_64 from
a LFS 6.1 (32-bit) system. I've noticed a few small errors that I would
like to report.
5.4. Build Variables
Following the commands will set LFS_TARGET to i686-pc-linux-gnu, which
works until building glibc. Changing LFS_TARGET to x86_64-pc-linux-gnu
allowed me to complete the build.
7.10. Creating the passwd, group, and log Files
The cat commands are missing ${LFS} so it tries to write to the root.
7.16. LFS-Bootscripts-3.2.2
Should include a block to set-up ${LFS}/etc/sysconfig/clock because the
boot reports an error when running the clock script.
One minor points
A few of the instructions in chapter 6 say something like:
echo "am_cv_func_working_getline=yes" >> config.cache
CC="${CC} ${BUILD64}" ./configure ...
wouldn't it be better to say:
echo "am_cv_func_working_getline=yes" > config.cache
because if the configure has already been run then the cache file should be
truncated.
Thanks for writing this, it's great.
HTH
Duncan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Version 7.0-cross-lfs-20051023-x86_64
Ken Moffat wrote:
On Mon, 24 Oct 2005, Duncan Webb wrote:
Hi all,
Just build the boot stages of Version 7.0-cross-lfs-20051023-x86_64
from a LFS 6.1 (32-bit) system. I've noticed a few small errors that
I would like to report.
5.4. Build Variables
Following the commands will set LFS_TARGET to i686-pc-linux-gnu,
which works until building glibc. Changing LFS_TARGET to
x86_64-pc-linux-gnu allowed me to complete the build.
The book (5.3) says:
| Now you will need to set the target triplet for the target
| architecure. You can do this by running the same command as above,
| just running it on the target machine. If you can't run the command
on | the target machine, you can use the table at the bottom of this
page.
What's the problem ?
Sorry, didn't make that too clear, but typing in the commands exactly as
described set my LFS_TARGET to i686-pc-linux-gnu which was incorrect.
The cause was because I was building the stuff on an Athlon64 build only
using 32bit code. I did work it out but it took some time and a lot of
googling.
What would have helped is an example of what they should be set to. I
didn't realise that the table represented the value of LFS_TARGET.
One minor points
A few of the instructions in chapter 6 say something like:
echo "am_cv_func_working_getline=yes" >> config.cache
CC="${CC} ${BUILD64}" ./configure ...
wouldn't it be better to say:
echo "am_cv_func_working_getline=yes" > config.cache
because if the configure has already been run then the cache file
should be truncated.
I've assumed that _some_ architectures already write to config.cache
in these cases, but I haven't looked too deeply (the aim is to keep
the text common between the different architectures, so e.g. the
multilib/foo-64.xml will include chunks from common/foo.xml). Maybe
there is a better way to set it out ? - obviously just '>config.cache'
would do it in all cases where it is needed, but it would look clunky.
Wouldn't think that it would make any difference which architecture you
use there shouldn't be a config.cache until either one in initialised as
described or configure has been run once.
Ken
9.4. Expect-5.43.0
I think the configure line should be:
CC="gcc ${BUILD64}" ./configure --prefix=/tools --with-tcl=/tools/lib \
--with-tclinclude=$TCLPATH --with-x=no
because the tools have not yet been built to default to 64bit.
10.3. Glibc-20050926
Got an error during make check, did make install and then make check
again, the check had no error after the install, odd behaviour.
Hope this helps
10.5. Binutils-2.16.1
I'm getting there errors which running check, any idea what I should do?
Running /sources/binutils-2.16.1/ld/testsuite/ld-bootstrap/bootstrap.exp ...
FAIL: bootstrap
FAIL: bootstrap with strip
FAIL: bootstrap with --traditional-format
FAIL: bootstrap with --no-keep-memory
FAIL: bootstrap with --relax
Running /sources/binutils-2.16.1/ld/testsuite/ld-cdtest/cdtest.exp ...
FAIL: cdtest
FAIL: cdtest with -Ur
TIA
Duncan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Version 7.0-cross-lfs-20051023-x86_64
Ken Moffat wrote:
On Mon, 24 Oct 2005, Duncan Webb wrote:
9.4. Expect-5.43.0
I think the configure line should be:
CC="gcc ${BUILD64}" ./configure --prefix=/tools --with-tcl=/tools/lib \
--with-tclinclude=$TCLPATH --with-x=no
because the tools have not yet been built to default to 64bit.
No, in the previous section where you build tcl you should have used
a sed on Makefile.in to force lib64, and also passed
--libdir=/tools/lib64.
But please read the rest of my reply!
There is no sed nor --libdir=/tools/lib64 in the pure64 book in chapter
9. Constructing a Temporary Tools in the pure book.
10.3. Glibc-20050926
Got an error during make check, did make install and then make check
again, the check had no error after the install, odd behaviour.
Your *next* point, and the absence of 32-bit in this package name,
make me think you've switched to pure64 (x86_64-64) AFTER following
the multilib book in the initial chapters. Perhaps, you came back to
it and mixed the different architectures ?
I've only build the pure64 section and not the multilib, I'm certain of
this. I have as far as I know followed the book to the letter but it is
easy to miss a line even when double checking everything. I have been
really careful and triple check the early stages, put the commands into
a build script and checked them before running the script.
FWIW, in 20050926 64-bit I see *an* error (in wcsmbs, from memory -
my logs are on another box). Haven't tried running check after
installing the 64-bit libc, but the error seems to have gone in last
week's snapshot. For 32-bit libc I'm getting a mass of errors in make
check, but nobody else has commented on them, so it could be an error
in my buildscripts.
I think that was where it was too.
Hope this helps
10.5. Binutils-2.16.1
I'm getting there errors which running check, any idea what I should do?
Running
/sources/binutils-2.16.1/ld/testsuite/ld-bootstrap/bootstrap.exp ...
FAIL: bootstrap
FAIL: bootstrap with strip
FAIL: bootstrap with --traditional-format
FAIL: bootstrap with --no-keep-memory
FAIL: bootstrap with --relax
Running /sources/binutils-2.16.1/ld/testsuite/ld-cdtest/cdtest.exp ...
FAIL: cdtest
FAIL: cdtest with -Ur
In pure64 (at least for x86_64-64) this seems "normal". I spent an
hour or two looking at the ld test suites last week after confirming
that multilib passes all of the binutils tests, but so far I haven't
even identified what is failing, or why.
Most likely an error in the test scripts, as all the subsequent builds
have and their tests have succeeded without errors.
Hopefully, I won't offend you when I say that you need to follow ONE
architecture (multilib, or pure64) at a time, and when I point out
that pure64 on amd64 works reasonably well _except_ for grub, and that
multilib x86_64 has some issues with perl (see Ryan's reply to me last
week on this list).
I'm not at all offended, my goal is only to help by reporting any errors
that I came across. I wont report an error unless I'm pretty certain and
checked the step and previous steps.
Initially, I started from a gentoo 64 system, then build a LFS 6.1
system straight from the book and now the pure64 system, using the LFS
6.1 as the host system. (The gentoo system wouldn't build the glibc in
chapter 5, it think it was failing in the nscd directory). I've run all
the checks for each of the builds, when they exist. I did delete the
/tools and /cross-tools directories and cleaned up the /sources
directory between attempts.
The only thing that I did was to follow the steps in chapter 7. If You
Are Going to Boot and then successfully rebooted but didn't carry
building from there as it's hard to read from one screen and type to
another, instead I rebooted again into gentoo and then followed the
steps in chapter 8 If You Are Going to Chroot, then it's easy to copy
and paste the instructions into a build script.
Everything so far is working fine and many thanks for all the hard work.
Duncan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
login.defs in 10.44 Shadow-4.0.13
etc/login.defs.linux seems to have been renamed to etc/login.defs, therefore the build for Shadow-4.0.13 fails on the sed command that generates /etc/login.defs in chapter 10.44. Shadow-4.0.13. This is a change between 12 and 13 should be: sed -e'[EMAIL PROTECTED]@MD5_CRYPT_ENAB yes@' \ -e 's@/var/spool/mail@/var/mail@' \ etc/login.defs > /etc/login.defs Regards, Duncan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[OT] Strace
I know this is off topic, so don't shout at me... I was trying to build strace-4.5.12 under x86_64 but it has compilation problems. Attached is a patch, taken from gentoo that fixes there. Regards, Duncan strace-4.5.12-gentoo.patch.bz2 Description: Binary data -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Version 7.0-cross-lfs-20051023-x86_64
Ken Moffat wrote:
On Tue, 25 Oct 2005, Duncan Webb wrote:
Ken Moffat wrote:
On Mon, 24 Oct 2005, Duncan Webb wrote:
9.4. Expect-5.43.0
I think the configure line should be:
CC="gcc ${BUILD64}" ./configure --prefix=/tools
--with-tcl=/tools/lib \
--with-tclinclude=$TCLPATH --with-x=no
because the tools have not yet been built to default to 64bit.
No, in the previous section where you build tcl you should have
used a sed on Makefile.in to force lib64, and also passed
--libdir=/tools/lib64.
But please read the rest of my reply!
There is no sed nor --libdir=/tools/lib64 in the pure64 book in
chapter 9. Constructing a Temporary Tools in the pure book.
OK, in that case, I was misled by the x86_64 subject. Apologies.
Ah, I see, you are objecting to the missing ${BUILD64}. My take on
this is that we've built a 64-bit-only compiler in pure64
(/tools/bin/gcc).
Well all I can say is that without it the build fails. Most of the
packages in Chapter 9 also required it.
Duncan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [OT] Strace
Ken Moffat wrote: On Tue, 25 Oct 2005, Duncan Webb wrote: I know this is off topic, so don't shout at me... I was trying to build strace-4.5.12 under x86_64 but it has compilation problems. Attached is a patch, taken from gentoo that fixes there. Regards, Duncan Blimey, it's a bit big, isn't it ;) I've got a somewhat shorter patch http://www.kenmoffat.uklinux.net/patches/strace-4.5.12-quota_fixes-1.patch - can't remember if I've tested it on x86_64-64 (thought I had, but maybe not), it's to address the problem caused by using a glibc snapshot which knows about the second version of LINUX_QUOTA_VERSION. I haven't submitted mine to patches@ because strace was tagged for 4.5.13, so I'm expecting it to be released soon. Does x86_64 have other problems with strace ? My rule of thumb for Beyond-Cross-LFS, at the moment, is to mention issues on blfs-support. Ken 94K... Just applied all the gentoo patches that where applied to the amd64 build and then diff'ed it. Sorry about posting it here, thought that blfs would have been better, but they don't install strace in the blfs book. Only because stupid *shadow* exits uncleanly when /etc/login.defs does not exist. Time to build a patch for shadow... Duncan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: login.defs in 10.44 Shadow-4.0.13
Duncan Webb wrote: etc/login.defs.linux seems to have been renamed to etc/login.defs, therefore the build for Shadow-4.0.13 fails on the sed command that generates /etc/login.defs in chapter 10.44. Shadow-4.0.13. This is a change between 12 and 13 should be: sed -e'[EMAIL PROTECTED]@MD5_CRYPT_ENAB yes@' \ -e 's@/var/spool/mail@/var/mail@' \ etc/login.defs > /etc/login.defs Regards, Duncan Small patch to write a message when shadow fails because login.defs is missing, it still writes the syslog message. But the user gets some feedback why it failed. Duncan shadow-4.0.13-missing-config.patch.bz2 Description: Binary data -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: login.defs in 10.44 Shadow-4.0.13
Matthew Burgess wrote: Duncan Webb wrote: Small patch to write a message when shadow fails because login.defs is missing, it still writes the syslog message. But the user gets some feedback why it failed. Thanks Duncan. As shadow is actively maintained, would you mind submitting this upstream please? We can then pick it up in their next release, which from their recent release activity shouldn't be too long at all. Regards, Matt. Done Regards, Duncan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [OT] Strace
Ken Moffat wrote: On Tue, 25 Oct 2005, Duncan Webb wrote: I know this is off topic, so don't shout at me... I was trying to build strace-4.5.12 under x86_64 but it has compilation problems. Attached is a patch, taken from gentoo that fixes there. Regards, Duncan Blimey, it's a bit big, isn't it ;) I've got a somewhat shorter patch http://www.kenmoffat.uklinux.net/patches/strace-4.5.12-quota_fixes-1.patch - can't remember if I've tested it on x86_64-64 (thought I had, but maybe not), it's to address the problem caused by using a glibc snapshot which knows about the second version of LINUX_QUOTA_VERSION. I haven't submitted mine to patches@ because strace was tagged for 4.5.13, so I'm expecting it to be released soon. Does x86_64 have other problems with strace ? My rule of thumb for Beyond-Cross-LFS, at the moment, is to mention issues on blfs-support. Are you thinking of a dedicated Cross-LFS mailing list? Ken Oops, I did screw up that patch, somehow I created a process.c.orig :-[ This one should do the trick. Duncan strace-4.5.12-gentoo.patch.bz2 Description: Binary data -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Linux-Libc-Headers-2.6.12.0 problem
I think that there's a small problem with installation of chapter 10 Linux-Libc-Headers-2.6.12.0 installation. I creates a the file /usr/include/linux/config.h with the lines: #error "Compilation aborted. Please read the FAQ for linux-libc-headers package." #error "(can be found at http://ep09.pld-linux.org/~mmazur/linux-libc-headers/doc/)" The FAQ says that most users want to empty this file but in gentoo and my older LFS 4 build I've this in the config.h #ifndef _LINUX_CONFIG_H #define _LINUX_CONFIG_H #include #endif This config.h and autoconf.h come from the kernel build. Question is what to do, empty or copy these two files from the kernel build. TIA Duncan BTW only noticed this when building Xorg. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Version 7.0-cross-lfs-20051024-x86_64 missing section
I think that there is a missing section in 11.9. The Bash Shell Startup Files, there doesn't seem to be anywhere that the PATH is set. In chapter 7. If You Are Going to Boot section 7.14. Setting Up the Environment the PATH is written but never gets overridden. At least I can't find where it gets reset *and* I think that this applies also the LFS 6.1 BTW There is a slight conflict with groups, sshd uses group 50 but 50 has been assigned to operator in chapter 8.8. Creating the passwd, group, and log Files. Regards, Duncan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Linux-Libc-Headers-2.6.12.0 problem
Andrew Benton wrote: Tobias Lieber wrote: I think that there's a small problem with installation of chapter 10 Linux-Libc-Headers-2.6.12.0 installation. I creates a the file /usr/include/linux/config.h with the lines: #error "Compilation aborted. Please read the FAQ for linux-libc-headers package." #error "(can be found at http://ep09.pld-linux.org/~mmazur/linux-libc-headers/doc/)" The FAQ says that most users want to empty this file but in gentoo and my older LFS 4 build I've this in the config.h #ifndef _LINUX_CONFIG_H #define _LINUX_CONFIG_H #include #endif This config.h and autoconf.h come from the kernel build. Question is what to do, empty or copy these two files from the kernel build. TIA Duncan BTW only noticed this when building Xorg. Hi you should copy these files from your kernel-build. Bullshit. You should never copy the raw headers from your kernel. You should have followed the instructions for installing xorg in BLFS. Xorg wouldn't be looking for the kernel headers at all if you'd used the command sed -i -e "[EMAIL PROTECTED] @/* & */@" \ `grep -lr linux/config.h *` The xorg error really not relevant because if LFS did "> /usr/include/linux/config.h" after installing the linux-libc-headers then xorg would not need the sed. What about other packages that may try including linux/config.h, wouldn't they also need to be patched? So the cleanest thing would be to do as the FAQ says and empty linux/config.h. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Version 7.0-cross-lfs-20051024-x86_64 missing section
Jim Gifford wrote: Duncan Webb wrote: I think that there is a missing section in 11.9. The Bash Shell Startup Files, there doesn't seem to be anywhere that the PATH is set. That is correct In chapter 7. If You Are Going to Boot section 7.14. Setting Up the Environment the PATH is written but never gets overridden. Explain what you mean. When you boot into the cross-lfs, this will setup you PATH to what is needed to complete to book. That's correct the path is set to complete all the packages in the book; then a reboot to bring up the new LFS system but the path still has the /tools/bin:/tools/sbin in it. Of course, BLFS will later correct this but I would have thought that LFS would have a correct path when it has been completed. Which route is take chroot or boot the resulting files should be the same. Duncan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[PATCH] uname
After patch -Np1 -i ../coreutils-5.2.1-uname-2.patch uname gives: uname -m x86_64 uname -p x86_64 uname -i x86_64 The attached patch from the gentoo's coreutils-5.2.1-patches-0.11.tar.bz2 gives: uname -m x86_64 uname -p AMD Athlon(tm) 64 Processor 3000+ uname -i AuthenticAMD Regards, Duncan coreutils-5.2.1-uname-gentoo.patch.bz2 Description: Binary data -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Udev changes (was Re: ALSA modules and restore volumes)
Matthew Burgess wrote:
Forwarding from blfs-dev, where an ALSA related thread went just a
little off-topic for BLFS :)
Thanks Alexander, I'll try to get these changes in a.s.a.p.
Matthew Burgess wrote:
I'll have to bite the bullet and see to getting all the module
hotplugging related bugs sorted out
This means just the following steps:
1) Upgrade udev to 071 to resolve the udev_run_hotplugd installation bug
2) Add these two rules to LFS default rules file:
ENV{UDEVD_EVENT}=="1", RUN+="/sbin/udev_run_hotplugd"
RUN+="/sbin/udev_run_devd"
Don't think that RUN+="/sbin/udev_run_devd" is requires for LFS as it
doesn't use devfs any more.
3) Change instructions to:
make EXTRAS=extras/run_directory/
make EXTRAS=extras/run_directory/ install
cp ../udev-config-5.rules /etc/udev/rules.d/25-lfs.rules
install -m644 -D docs/writing_udev_rules/index.html \
/usr/share/doc/udev-071/index.html
After that ends up in the book, we can try eliminating the hotplug
package gradually. E.g., for a start, build the firmware helper in
EXTRAS and use it instead of hotplug's firmware.agent.
Some cleanup of the current rules file is also needed. E.g., I would
change the following rules:
KERNEL=="dm-*", GROUP="disk", MODE="0640"
KERNEL=="card*", NAME="dri/card%n", GROUP="video"
to
KERNEL=="dm-*", NAME=""
KERNEL=="card*", NAME=""
in order for udev to completely ignore the corresponding devices.
Rationale:
dm: /dev/dm-* is not the proper name for such devices. Both "dmsetup"
and lvm2-related programs make the corresponding devices automatically
and with proper names, without udev and associated races.
card*: the X server makes those devices anyway without any help from
udev. I don't want udev to step on its back (aka race with permissions)
and recreate the devices.
I think that you can also add:
Add the rules to /etc/udev/rules.d/60-hotplug.rules
#
# usbfs-like device nodes
SUBSYSTEM="usb_device", PROGRAM="/bin/sh -c 'X=%k X=$${X#usbdev}
B=$${X.*} D=$${X#*.}; echo bus/usb/$$B/$$D'", SYMLINK+="%c"
# be backward compatible for a while with the /etc/dev.d and
/etc/hotplug.d/ systems
# run /etc/hotplug.d/ stuff only if we came from a hotplug event, not
for udevstart
ENV{UDEVD_EVENT}=="1", RUN+="/sbin/udev_run_hotplugd"
I'm not 100% sure but I think that pciutils (plus
pcimodules-pciutils-2.1.11.diff patch) and usbutils are also needed.
Build usbutils with:
./configure \
--prefix=/usr \
--sysconfdir=/etc \ #may not re required
--datadir=/usr/share \
--enable-usbmodules
To log hotplug events you could also add:
in /etc/hotplug/hotplug.functions change the lines:
if [ -t 1 or -z "$LOGGER" ]; then
to
if [ -z "$LOGGER" ]; then
and
$LOGGER -t $(basename $0)"[$$]" "$@"
to
$LOGGER -p local1.info -t $(basename $0)"[$$]" "$@"
Add to /etc/syslog.conf
local1.* -/var/log/hotplug.log
or
local1.* -/var/log/hotplug/messages.log
The syslog needs to be started after mounting the file systems rw and
before hotplugging.
Works for me.
Duncan
BTW Acpid is also quite useful for laptops and powering down by a quick
press of the power button.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Udev changes
Alexander E. Patrakov wrote:
Duncan Webb wrote:
Matthew Burgess wrote:
Forwarding from blfs-dev, where an ALSA related thread went just a
little off-topic for BLFS :)
2) Add these two rules to LFS default rules file:
ENV{UDEVD_EVENT}=="1", RUN+="/sbin/udev_run_hotplugd"
RUN+="/sbin/udev_run_devd"
Don't think that RUN+="/sbin/udev_run_devd" is requires for LFS as it
doesn't use devfs any more.
This is not for devfs! This is for compatibility with obsolete
packages that still install scriptlets into /etc/dev.d. I.e., after
/dev/lp0 is created, this rule executes the following scripts if they
exist:
/etc/dev.d/lp0/*.dev
/etc/dev.d/printer/*.dev
/etc/dev.d/default/*.dev
This may be used in order to download firmware into certain printers
(/etc/dev.d/lp0/firmware.dev contains "#!/bin/sh cat firmware
>/dev/lp0" then). More modern approach is to use RUN+=... rules
instead of dev.d scriptlets. BTW BLFS 6.1 uses a dev.d scriptlet for
ALSA volume restoration (BLFS SVN converted this to the RUN rule).
So you are right that LFS and BLFS SVN contain no such obsolete
packages that need /etc/dev.d.
I think that you can also add:
Add the rules to /etc/udev/rules.d/60-hotplug.rules
#
# usbfs-like device nodes
SUBSYSTEM="usb_device", PROGRAM="/bin/sh -c 'X=%k X=$${X#usbdev}
B=$${X.*} D=$${X#*.}; echo bus/usb/$$B/$$D'", SYMLINK+="%c"
Only after linux-2.6.14 please, and synchronously with patching libusb
in BLFS and removing the /proc/bus/usb mount. But those rules will of
course do no harm with earlier kernel.
# be backward compatible for a while with the /etc/dev.d and
/etc/hotplug.d/ systems
# run /etc/hotplug.d/ stuff only if we came from a hotplug event, not
for udevstart
ENV{UDEVD_EVENT}=="1", RUN+="/sbin/udev_run_hotplugd"
Correct. But that alone doesn't run /etc/dev.d stuff, you need
RUN+="/sbin/udev_run_devd" for that.
I'm not 100% sure but I think that pciutils (plus
pcimodules-pciutils-2.1.11.diff patch) and usbutils are also needed.
They are needed with 2.4 kernels only (i.e.: not needed at all in LFS)
for hotplug to work correctly. All the needed information is gathered
from sysfs with 2.6 kernels.
To log hotplug events you could also add:
What's wrong with the current way to log events into
/var/log/hotplug/events?
Nothing at all.
I was trying to figure out why nothing was being logged in
/var/log/hotplug/events, so I enabled the hotplug debug option then
there was quite a lot of output so I figured that it was better to keep
the log separate.
Thanks for the info, it's cleared up a few uncertainties that I had.
Duncan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Udev changes
Alexander E. Patrakov wrote:
Duncan Webb wrote:
Matthew Burgess wrote:
Forwarding from blfs-dev, where an ALSA related thread went just a
little off-topic for BLFS :)
2) Add these two rules to LFS default rules file:
ENV{UDEVD_EVENT}=="1", RUN+="/sbin/udev_run_hotplugd"
RUN+="/sbin/udev_run_devd"
Don't think that RUN+="/sbin/udev_run_devd" is requires for LFS as it
doesn't use devfs any more.
This is not for devfs! This is for compatibility with obsolete
packages that still install scriptlets into /etc/dev.d. I.e., after
/dev/lp0 is created, this rule executes the following scripts if they
exist:
/etc/dev.d/lp0/*.dev
/etc/dev.d/printer/*.dev
/etc/dev.d/default/*.dev
This may be used in order to download firmware into certain printers
(/etc/dev.d/lp0/firmware.dev contains "#!/bin/sh cat firmware
>/dev/lp0" then). More modern approach is to use RUN+=... rules
instead of dev.d scriptlets. BTW BLFS 6.1 uses a dev.d scriptlet for
ALSA volume restoration (BLFS SVN converted this to the RUN rule).
So you are right that LFS and BLFS SVN contain no such obsolete
packages that need /etc/dev.d.
I think that you can also add:
Add the rules to /etc/udev/rules.d/60-hotplug.rules
#
# usbfs-like device nodes
SUBSYSTEM="usb_device", PROGRAM="/bin/sh -c 'X=%k X=$${X#usbdev}
B=$${X.*} D=$${X#*.}; echo bus/usb/$$B/$$D'", SYMLINK+="%c"
Only after linux-2.6.14 please, and synchronously with patching libusb
in BLFS and removing the /proc/bus/usb mount. But those rules will of
course do no harm with earlier kernel.
# be backward compatible for a while with the /etc/dev.d and
/etc/hotplug.d/ systems
# run /etc/hotplug.d/ stuff only if we came from a hotplug event, not
for udevstart
ENV{UDEVD_EVENT}=="1", RUN+="/sbin/udev_run_hotplugd"
Correct. But that alone doesn't run /etc/dev.d stuff, you need
RUN+="/sbin/udev_run_devd" for that.
I'm not 100% sure but I think that pciutils (plus
pcimodules-pciutils-2.1.11.diff patch) and usbutils are also needed.
They are needed with 2.4 kernels only (i.e.: not needed at all in LFS)
for hotplug to work correctly. All the needed information is gathered
from sysfs with 2.6 kernels.
To log hotplug events you could also add:
What's wrong with the current way to log events into
/var/log/hotplug/events?
Nothing at all.
I was trying to figure out why nothing was being logged in
/var/log/hotplug/events, so I enabled the hotplug debug option then
there was quite a lot of output so I figured that it was better to keep
the log separate.
Thanks for the info, it's cleared up a few uncertainties that I had.
Duncan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Suggestion for Cross-LFS doc.
Would it make sense to you guys to change section 5.4. Build Variables a bit. I would suggest: 1) Swap Configuration #1 and #2 around because the table belongs at #1. 2) Change the text a tiny bit from "Creating different architecture tools" to "If the build target is on a different architecture", etc. 3) Add something about the implication of this because it determines if you are going to boot or chroot. I think that you can only chroot if the target system's /bin/bash and /bin/env can be executed by the host system. Otherwise a you need to follow the steps in 7. If You Are Going to Boot From what I have figured out is that chroot is easier because the host system it still available and therefore X-windows, Firefox, etc are there to carry on reading the book. Hope that this make sense. Regards, Duncan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Cross X86_64 Question /usr/lib64
I've a question arising from the build of xorg. xorg decided to install it's libraries and modules into /usr/lib64 On a pure64 system this directory is not created. Question is: 1) should a symlink from /usr/lib to /usr/lib64 be created in the section Creating Directories in chapters 7 & 8 or 2) #define HaveLib64 NO in the xc/config/cf/host.def Regards, Duncan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross X86_64 Question /usr/lib64
Ken Moffat wrote: On Fri, 28 Oct 2005, Duncan Webb wrote: I've a question arising from the build of xorg. xorg decided to install it's libraries and modules into /usr/lib64 On a pure64 system this directory is not created. Question is: 1) should a symlink from /usr/lib to /usr/lib64 be created in the section Creating Directories in chapters 7 & 8 or 2) #define HaveLib64 NO in the xc/config/cf/host.def Regards, Duncan BLFS issues. Since the BLFS book is purely x86 at the moment, this sort of thing is better discussed on blfs-support. If you search the archives for blfs-support, you will find that pure64 wants three defines in host.def - HaveLib64 only controls the libGL symlink, you also want #define LibDirName lib #define LibDir /usr/X11R6/lib/X11 (obviously, the last of these assumes you are using the old /usr/X11R6, if you put pure64 X into /usr you'll have to document the issues yourself) Hint for search.linuxfromscratch.org: look for both x86_64 and pure64. I agree that xorg is a BLFS support issue and that deals with case 2. Case 1 is a bit like /usr/man link to /usr/share/man, which is a LFS cross issue. That's why I posted it here. Sorry if this was wrong. Duncan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
LFS-Bootscripts-3.2.1 setclock
Hi, Now that we're no longer in summer time in the Makefile for LFS-Bootscripts-3.2.1 there are no rules to install setclock during a reboot or shutdown. So the hardware clock is not being synchronised with the system clock. Regards, Duncan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-Bootscripts-3.2.1 setclock
Archaic wrote: On Thu, Nov 03, 2005 at 05:58:51AM -0100, Duncan Webb wrote: Now that we're no longer in summer time in the Makefile for LFS-Bootscripts-3.2.1 there are no rules to install setclock during a reboot or shutdown. So the hardware clock is not being synchronised with the system clock. It is not safe to assume that the system clock is more accurate than the hwclock unless you are syncing to a time server which is why BLFS adds the needed symlinks *after* NTP is installed and configured. Maybe I was not too clear. If the system clock is set to local time then when you shut-down the hardware clock should be set to system time. The setclock script has a stop case which never gets called because there is no KNNsetclock in rc0.d or rc6.d. As a consequence when the system is booted the time is about 1 hour out until the ntpdate is called. (If NTP has been installed.) -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-Bootscripts-3.2.1 setclock
Bryan Kadzban wrote: On Thu, Nov 03, 2005 at 08:28:12AM -0700, Archaic wrote: On Thu, Nov 03, 2005 at 09:47:54AM -0100, Duncan Webb wrote: Maybe I was not too clear. No, you were perfectly clear. If the system clock is set to local time then when you shut-down the hardware clock should be set to system time. And again, no. LFS cannot assume the sanity of the system clock so it should not write to the hwclock. NTP gives us the sanity, therefore, NTP is where the symlinks are made. This is all true in general, however, I'm starting to think that DST considerations might override that at 2 points during the year. If the user is running NTP, then there's no problem (and as you say, the symlinks are created when NTP is installed). If the user puts their RTC in UTC time, then there's also no problem. (So Duncan, this is your fix: Put your hardware RTC in the UTC timezone, then it won't have to change when DST starts or stops. If you dual boot to less intelligent OSes, then that's a poor fix, but it would at least prevent this problem. Or, set up NTP.) Running a NTP daemon requires a permanent internet connection. Dual boot usually requires the clock in local time, that's clear. What I don't understand is why anybody would have a problem syncing the hardware clock to the system clock at reboot/power off. After all the system clock is synced to the hardware clock at boot. Let's just assume that NTP is /not/ installed, then the clock is manually adjusted once in a while. Without the symlinks you would need to adjust the clock every time the machine is booted or enter the BIOS and fix the time. With the symlinks the hardware clock is adjusted automatically. Having a system with it time being perfectly correct is not essential for all applications, a minute here or there doesn't bother most people. But it is important that time does not jump around. Who want a log where the time at the beginning is later than now. I'm sorry but I just don't see the harm of setting the hardware clock at power off/reboot (with or) without NTP and running in UTC or local time. But if the RTC is in localtime, and localtime changes its offset from UTC, then perhaps the RTC should be offset at that time. It is true that we don't know whether the system clock or the hardware clock is more accurate in general, but if we're talking about an hour difference at DST switchover, the accuracy difference between the system and hardware clocks is likely miniscule in comparison. Note that I have no idea *how* the bootscripts could handle that, just that I think it may be appropriate to set the RTC in this one case. If it's impossible, then that's fine. BTW It can be quite helpful to have a dual boot, if only to check that some bleeding edge hardware driver is doing what it should. Or that some hardware is still working and doesn't have a hardware failure. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-Bootscripts-3.2.1 setclock
Ken Moffat wrote: On Thu, 3 Nov 2005, Duncan Webb wrote: What I don't understand is why anybody would have a problem syncing the hardware clock to the system clock at reboot/power off. After all the system clock is synced to the hardware clock at boot. In that case, please search the lfs archives and warm yourself by the heat of the discussion. A classic case for "your distro, your rules". Sort of guessed this by Archaic reaction. Never would have questioned it had the start case not synced to the hardware clock. Duncan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-Bootscripts-3.2.1 setclock
Archaic wrote: On Thu, Nov 03, 2005 at 11:02:49PM -0100, Duncan Webb wrote: Running a NTP daemon requires a permanent internet connection. Dual boot usually requires the clock in local time, that's clear. Absolutely and totally false. Please do your research before making such statements. I thought that ntpd, be default, syncs with the time server every five minutes and that you could use ntpdate in the cron to keep the system clock up-to-date (that is the what is said in the IPcop manual) and Windows stores time in local time. Don't quiet see what is totally false. What I don't understand is why anybody would have a problem syncing the hardware clock to the system clock at reboot/power off. After all the system clock is synced to the hardware clock at boot. I see Ken beat me to the punch WRT to both the "your distro, your rules" mantra, *and* the relevant discussions of old. When I took over the maintenance of the time hint (http://www.lfs-matrix.org/hints/downloads/files/time.txt) I, too, was of the opinion that the system clock would be more accurate than the hwclock. I was inundated with examples of that not being true and included one such example in the hint itself. Thus, the realization that we cannot assume which is more accurate. Good hint. BTW, depending on how *you* want to do things, you can either run ntpd manually from time to time or via cron and create the symlinks or forget ntpd altogether. It's completely your call. ;) There are other ways to sync time, such as the alevt-date command from the alevt package which syncs to teletext time. Quiet useful if the system is for a MythTV or Freevo box and not connected to the internet. Okay, may be a little note in the LFS book saying that the hardware clock is not set to the system clock because the hardware clock can be more accurate than the system clock. If in the case that the system clock is more accurate than the hardware clock then add the following sysmlinks... -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: User lfs is more than optional.
Archaic wrote: On Thu, Nov 17, 2005 at 10:08:07PM -, William Zhou wrote: (BTW, How do I reply to a specif thread instead of creating a new one? I tried to figure it out but I can't. Thanks.) You can't. You are using a crappy mail client. Download thunderbird. I use Thunderbird (1.0.7) but it won't scan the courier imap folders. There was some information in the FAQ about adding a variable to the prefs.js but it didn't work for me. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
