On 03-Jun-2002 Marvin Heffler wrote: > I started working with the LFS-based sample implementation a couple of > weeks ago and would like to share some of things I found to see if others > have seen the same thing or to find out what I did wrong. Here's what I > found. > > 1. Originally I worked with the manual process documented on the Linux From > Scratch web site. One of the beginning instructions tells you to create a > separate filesystem for the build and to mount it at /mnt/lfs. This causes > a problem with the multi-phase build of the SI because at some point it > tries to move /mnt/lfs to /mnt/lfs-harness. This produces a failure saying > /mnt/lfs cannot be removed since it is currently being used. The basic > problem is you cannot move a directory when it is the mount point for a > mounted filesystem. To get around this problem I simply mounted the > separate filesystem at /mnt. There may be other ways to fix this, such as > mounting the filesystem at /mnt/si and then modifying the xml files to use > /mnt/si/lfs instead of /mnt/lfs. >
The xml files in my si assume directories (which can be on another file system I presume). It then uses a 2.4 kernel feature which allows you to "mount" a directory onto another directory. > 2. The next problem I ran into was when it came time to build dummy-mta. > The src/si/entities/package is looking for the dummy-mta-1.2.tar.gz file, > but the pub/lsb/impl/lfs-si-update-20020508.tar.gz file has > dummy-mta-1.1.tar.gz. This mismatch causes the build to fail. Apparently > someone else figured this out because now there is a dummy-mta-1.2.tar.gz > file in the pub/lsb/impl directory. Since this was not available when I > doing my testing I worked around the problem by extracting the > dummy-mta-1.1.tar.gz file, changing the directory name from dummy-mta-1.1 > to dummy-mta-1.2, and then creating a new dummy-mta-1.2.tar.gz file. This > got me by the problem, but it didn't solve everything as demonstrated by my > next item. > > 3. After creating the dummy-mta-1.2.tar.gz file things went much further in > the build, but after two hours and thirty-five minutes it failed again when > trying to do "make install" on the dummy-mta-1.2 package. The makefile is > very simple only putting a sendmail file in /usr/sbin and then making a > symbolic link to /usr/lib/sendmail. This works fine in one of the earlier > phases, but it fails in the last phase because the sym link was already > there. To fix this problem I edited the makefile in dummy-mta-1.2 to use > "ln -sf" instead of "ln -s". After making this fix I was able to complete > building the si. > the reason for 1.2 was to add a DESTDIR option to the makefile. It should be on the ftp site now. > 4. After having the si completely built, I next tested to see if all the > commands listed in the LSB spec were in the si. The only one I found > missing was /usr/bin/lsb_release. To resolve this I copied the > /usr/bin/lsb_release and /etc/lsb-release files from my Red Hat 7.3 system > to the si. > Correct, i have not created this file yet. Keep meaning to add it to the TODO. Thanks for the reminder. > 5. Next I ran lsblibchk on the si to see if all the libraries were there. > It reported all the X11 libraries as missing. I seem to remember someone > saying this was a known problem and was being worked on. > correct. > 6. The other general question I have is how to restart nALFS so it can > continue the build. When I was testing and ran into the problems described > above, each time I deleted everything in /mnt/lfs and started over. It > seems to me there must be some way to resolve the immediate problem and > pick up where nALFS left off. I would appreciate it if someone could tell > me if this is possible and how to do it. > The problem lies in nALFS. It expects to follow the recipe and gets confused if you "jump" a step. Fixing this will require some work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with subject of "unsubscribe". Trouble? Email [EMAIL PROTECTED]
