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.
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
