6.1 release branch

Bryan Kadzban bryan at kadzban.is-a-geek.net
Sun Apr 3 12:50:14 PDT 2005


Bryan Kadzban wrote:
> If I run into other issues, I'll post them then.  I've just finished 
> compiling binutils pass 1 (yes, by hand, I have a whole weekend ;-) ).
> 

Well, I ran into two issues, but both of them seemed to be caused by my
own mistakes (I really should come up with a scripted build system one
of these days...  ;-) ), because they didn't happen the second time through.

First, all the binutils programs were still hardwired to the dynamic
linker in /lib, not /tools/lib, so nothing would compile once I got to
chapter 6.  I believe I failed to actually "make install" binutils pass
2 (though I did edit the gcc specfile, because other programs worked).
I started over.  (Grr... but oh well, my mistake.)

Second, I used the pkg-user hint (as I always do).  That's not in and of
itself a problem, but I missed the comment about the /usr/bin/perl
symlink being owned by root.  I also missed the fact that perl's "make
install" did not overwrite that symlink.  So when I got to autoconf, it
failed to build, because the chapter 5 Perl did not have Data::Dumper
installed (and /usr/bin/perl was in /tools).  Rebuilding and installing
perl (after chowning the symlink), texinfo (just in case) and autoconf
fixed it.

So I think both of those are my fault, not the book's.

For the record, I also ran into the glibc tst-cancel17 and tst-cancelx17
failures in chapter 6 (on kernel 2.6.11.5), but I know the cause is the
kernel.


I also saw a couple more issues in the text, first in section 7.4
("Device and module handling").  In the intro, the book says:

> Because these device nodes will be created each time the system
> boots, they will be stored on a ramfs (a file system that resides
> entirely in memory and does not take up any disk space).

We use a tmpfs now, not a ramfs.

In 7.4.2 (second para from the end), the book says:

> With udev, this method will not work because the device node does not
> exist until the module is loaded. To solve this, the S05modules
> bootscript was added to the lfs-bootscripts package, along with the
> /etc/sysconfig/modules file. By adding module names to the modules
> file, these modules will be loaded when the computer is starting up.

The hotplug init script calls the *.rc hotplug files, to load the
appropriate modules for the hardware that's always installed.  There's
no need to add anything to /etc/sysconfig/modules for those devices.

The only thing that doesn't handle is true hotplugging hardware, like
USB or PCI-X devices that aren't always in (PCI-X is hotpluggable,
right?) or Firewire.  Maybe something like this would be better:

> With udev, this method will not work...  To solve this, the LFS
> bootscripts call some scripts provided by the Hotplug package.  These
> scripts determine what hardware is present in the system at boot
> time, and load the appropriate kernel modules (as long as those
> modules are not listed in /etc/hotplug/blacklist).
> 
> However, this does not work unless the hardware is installed at boot
> time -- USB devices that aren't plugged in at boot, for example, will
>  not have their drivers loaded through the Hotplug scripts.  For this
>  case, it is possible to use the S05modules script, which reads the
> /etc/sysconfig/modules file.  Any module names added to the modules
> file will be loaded when the computer starts up.

This still meshes fairly well with the wording in 7.4.3, except for one
little thing:  in that section, the book says:

> When the Hotplug package is installed, it will respond to the
> aforementioned kernel's bus driver hotplug events. The Hotplug
> package will load the appropriate module and make this device
> available by creating the device node(s) for it.

We install Hotplug already, although it doesn't seem to be used (except
to load modules at boot time, with the .rc scripts, as above).  Maybe
this would be more appropriate:

> When the Hotplug package's main /sbin/hotplug script is registered as
> the system hotplug event handler, it will respond to the ...

and continue as before.  There were issues discussed on this list with
doing this in the book (registering the hotplug script as the main
handler), but I don't remember what they were anymore.


In section 8.3, the book says:

> The kernel configuration file .config  produced by the make
> menuconfig step above contains all the configuration selections for
> the kernel that was just compiled. It is a good idea to keep this
> file for future reference:
> 
> cp .config /boot/config-2.6.11.6

It might be worth mentioning that 2.6 kernels can provide their
configuration in a /proc/config.gz file, if they've been configured to
do so (CONFIG_IKCONFIG and CONFIG_IKCONFIG_PROC).  If you don't enable
the _PROC setting, you can still get at the configuration, but you'll
need the scripts/extract-ikconfig script from the kernel to do it.

IMO, it makes more sense to do it this way, so you don't get confused
which kernel's config file you're looking at.  But that's just me.  I
think it should still be mentioned, at least.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20050403/135f4bc5/attachment.sig>


More information about the lfs-dev mailing list