[lfs-support] lfs-support Digest, Vol 969, Issue 1

Bruce Dubbs bruce.dubbs at gmail.com
Mon Jul 9 09:12:11 PDT 2018

On 07/09/2018 10:14 AM, Alan Corey wrote:
> Please bear with me, I just turned off digest mode.  I'll use filters
> and folders to deal with random traffic.  I'm on Gmail, mostly use the
> web client.  I'm still on half a dozen mailing lists but mostly I use
> forums these days.  Trying to set up a real mail reader that does
> quoting properly.  It probably won't be Thunderbird.  I have years
> worth of mail in my Gmail account which with imap usually isn't a
> problem.  Thunderbird is taking hours over this cell phone connection
> downloading something to catch up.  My second choice would be Alpine.
> Anyway, trying to fudge some quoting here.
>> Untar package cd package dir follow book, always remove the used dir
>> after you have built it.
> Hmm, doesn't removing the directory cause "make uninstall" to not
> work?  Guess I'll find out.

We don't really address uninstall.  That's really part of package 
management which we do not directly support.

>> Did you also run the version check script chapter 2.2?
> Yes, looks fine.
>> Whys is there no lost+found in /mnt/lfs?  If you mounted your lfs
>> partition on /mnt, it should be there.  However the rest looks OK.
> The lost+found is in the partition outside the lfs dir.  That's part
> of what I meant by it being confusing what you wanted.  I initially
> created an /lfs mountpoint.  This is /dev/sda2 mounted on /mnt and it
> has an lfs directory in it.

That will not work.  When you get to the point of rebooting into LFS, 
you need your build to be at the root of the file system.  I suggest:

umount /lfs
mkdir -p /mnt/lfs
mount /dev/sd?? /mnt/lfs

>> Looks OK, except you did not mention the symbolic link:
>> /tools -> /mnt/lfs/tools
> It's there as of yesterday.  I'm trying to think of what the chroot is
> going to see, if I do a chroot /mnt/lfs it will see the tools dir as
> /tools so it works like the symink when I'm not chrooted.  Got it.
>> So your CPU is ARM, isn't it? I guess not many people on this list have
>> experience with that architecture. This does not mean they can't help, but
>> their support may be limited.
> Yes it is.  The most significant differences I've found are the boot
> methods and the video coming from a GPU sharing board and memory with
> the CPU.  And the default file system is an SD card.  Other than that
> this $35 cigarette pack sized computer thinks it's a mainframe.  I'm
> in the Debian, OpenBSD, NetBSD and FreeBSD ARM mailing lists BTW, 635
> posts on https://www.raspberrypi.org/forums/.  LFS is the new kid on
> my block.
>> Does compiling a simple program work?
> Yes, I do it several times a week at least.  I'd really rather be
> writing C than messing around with operating systems.  But I sort of
> made a career of replacing operating systems, mostly Windows, retired
> now.
>> together is easiest if you have a spare x86_64 partition where you
> I do, but not on this machine.  Thinking ahead, I should be able to
> able to build images to work on several different types of
> architectures with this tools collection I'm setting up.  One of those
> is x86_64, also a couple different arm64 ones

That sounds good, but we suggest your first build be on x86_64 to 
minimize problems that may come up.

>> If that machine is some sort of Raspberry Pi,
> Yes, I have 5 of them now.  This is running Debian:
>    Linux version 4.16.0-2-arm64 (debian-kernel at lists.debian.org) (gcc
> version 7.3.0 (Debian    7.3.0-23)) #1 SMP Debian 4.16.16-2
> (2018-06-22)
> The rest run Raspbian.  I also have a Rock64 and a Pocket Beagle both
> with Debian.  The ARMs outnumber the Intel and AMD about 3:1.
>> Another thing that trips up new users is doing some things as root.
> I confess I've never administered a multi-user unix machine.  I'm used
> to doing everything as root, it's hard to remember what works as
> non-root.  But I'm trying to do as much of this as possible as the lfs
> user so lfs will own files and dirs.

Doing everything as root is a recipe for problems.  Eventually you will 
make a mistake you will regret.   That is why we build Chapter 5 as user 
lfs.  If a mistake is made, it won't hose the host.  Same rationale for 
building Chapters 6,7,8 in chroot.

> I hope to build arm64 images to run on the Raspberry Pis and Rock64,
> and an x86_64 to replace a dead Debian partition on a laptop.  Maybe I
> should do the x86_64 first since there aren't booting issues.  I can
> burn it a CD/DVD and copy it to the laptop.

That can be done, but you have to be careful when copying to a lesser 
CPU.  See the second note in Section 6.17. GMP-6.1.2.

If the laptop boots now, you don't need to burn a DVD.  Just create a 
tarball of /mnt/lfs and extract it to an empty partition on the other 
system.  There will need to be some customization in fstab and 
networking. If the laptop does not already have grub installed, you will 
need to install it separately.

   -- Bruce

More information about the lfs-support mailing list