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

Alan Corey alan01346 at gmail.com
Mon Jul 9 08:14:14 PDT 2018


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.

> 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.

> 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.

> 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.

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.


On 7/8/18, lfs-support-request at lists.linuxfromscratch.org
<lfs-support-request at lists.linuxfromscratch.org> wrote:
> Send lfs-support mailing list submissions to
> 	lfs-support at lists.linuxfromscratch.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.linuxfromscratch.org/listinfo/lfs-support
> or, via email, send a message with subject or body 'help' to
> 	lfs-support-request at lists.linuxfromscratch.org
>
> You can reach the person managing the list at
> 	lfs-support-owner at lists.linuxfromscratch.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of lfs-support digest..."
>
>
> Today's Topics:
>
>    1. Re: Booting LFS with systemd (Michael Shell)
>    2. Building LFS under Debian (Alan Corey)
>    3. Re: Building LFS under Debian (spiky)
>    4. Re: Building LFS under Debian (spiky)
>    5. Re: Building LFS under Debian (Bruce Dubbs)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 7 Jul 2018 23:34:29 -0400
> From: Michael Shell <list1 at michaelshell.org>
> To: lfs-support at lists.linuxfromscratch.org
> Subject: Re: [lfs-support] Booting LFS with systemd
> Message-ID: <20180707233429.305eaf827aeeaec45c447b00 at michaelshell.org>
> Content-Type: text/plain; charset=US-ASCII
>
> On Sat, 07 Jul 2018 14:38:36 +0800
> Xi Ruoyao <ryxi at stu.xidian.edu.cn> wrote:
>
>> For example I can insert
>>
>>     log_info("I am still alive!!!");
>>
>> into systemd source code somewhere.
>
>
>   Xi,
>
> Thanks! Yeah, that's a good approach for developers. But, a lot of users
> aren't going to be able to do that.
>
>> Systemd seems to handle errors well (most of time). SIGABRT is strange.
>> Someone said "-D_FORTIFY_SOURCE=2" may cause systemd to SIGABRT.
>
> That's something else Frans can try (disable D_FORTIFY_SOURCE when
> compiling systemd). Also, doing a search based on the above, I found this
> which states that a watchdog timer can also trigger a SIGABRT:
>
> https://lists.libreswan.org/pipermail/swan-dev/2016-July/001587.html
>
> So, Frans can also try disabling the systemd watchdog timer:
>
> edit /etc/systmed/system/ipsec.service and set
>
> WatchdogSec=0
>
> and see if that changes anything.
>
>
>   Cheers,
>
>   Mike
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 8 Jul 2018 12:25:43 -0400
> From: Alan Corey <alan01346 at gmail.com>
> To: lfs-support at lists.linuxfromscratch.org
> Subject: [lfs-support] Building LFS under Debian
> Message-ID:
> 	<CAOh3dDa9n7bOcdoRYFjsXW84Dtya-ULirAA+Ve9R7sfhw=ouPw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> LFS is a work of art, I can't believe it's been around 20 years and
> I'd never heard of it.  20 years ago I was downloading Slackware on
> floppies and lugging them home from college.
>
> The paths are sort of intricate to a newcomer though.  There are the
> paths I see, the paths the chroot is going to see, then paths used as
> prefix and lib-path.  At couple diagrams might help in the beginning.
> I'm still stuck on binutils, chapter 5,
> http://www.linuxfromscratch.org/lfs/view/stable/chapter05/binutils-pass1.html
>
> I started out making a mountpoint called /lfs to mount the partition
> I'm working in, then decided it was a bad idea.  What I have looks
> like:
>
> /lost+found
> /media
> /mnt
>   lfs
>     sources
>       binutils-2.30
>         build
>     tools
> /opt
> /proc
>
> Filezilla has nice directory trees BTW if somebody wants to do
> screenshots for documenting.  :)  Anyway I'm not sure that's right.
> Does the page mean to make build inside of binutils or is it outside
> to be used again later?  My $LFS is set to /mnt/lfs
>
> I made a little cfg script for consistency rather than doing it from
> memory, it's mostly copied from the web page:
> #!/bin/sh
> ../configure --prefix=/tools            \
>   --with-sysroot=$LFS        \
>   --with-lib-path=/tools/lib \
>   --target=$LFS_TGT          \
>   --disable-nls              \
>   --disable-werror
>
> configure echos it back as
>  ../configure --prefix=/tools --with-sysroot=/mnt/lfs
> --with-lib-path=/tools/lib --target=aarch64-lfs-linux-gnu
> --disable-nls --disable-werror
>
> in the config.log.  OK, I'll attach the log.
>
> What worries me is the
> gcc: error trying to exec 'as': execvp: Too many levels of symbolic links
> In the conftest.  Debian has this kludgy alternatives system where gcc
> is /usr/bin/gcc but that's
> lrwxrwxrwx 1 root root 5 Apr  4 06:16 gcc -> gcc-7
> and that's
> lrwxrwxrwx 1 root root 23 Jun 26 03:52 gcc-7 -> aarch64-linux-gnu-gcc-7
> And aarch64-linux-gnu-gcc-7 is the real name of gcc 7
> maybe that's just part of conftest but configure dies with an error
> and no makefile.  as is:
> as -> aarch64-linux-gnu-as in /usr/bin
>
> These kludgy scripts, and PAM/Selinux/Apparmor are what I'm hoping to
> get away from with linuxfromscratch.   Yes, I usually have a few gcc
> and as and g++ versions around but it seems like there should be a
> better way.
>
>   Alan
>
> --
> -------------
> No, I won't  call it "climate change", do you have a "reality problem"? -
> AB1JX
> Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: config.log
> Type: text/x-log
> Size: 12176 bytes
> Desc: not available
> URL:
> <http://lists.linuxfromscratch.org/pipermail/lfs-support/attachments/20180708/33eb71ff/attachment-0001.bin>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 8 Jul 2018 17:31:30 +0100
> From: spiky <spiky0011 at gmail.com>
> To: lfs-support at lists.linuxfromscratch.org
> Subject: Re: [lfs-support] Building LFS under Debian
> Message-ID: <d3632778-e33e-2267-fb2a-43f7aaa768f4 at gmail.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
>
>
> On 08/07/18 17:25, Alan Corey wrote:
>> LFS is a work of art, I can't believe it's been around 20 years and
>> I'd never heard of it.  20 years ago I was downloading Slackware on
>> floppies and lugging them home from college.
>>
>> The paths are sort of intricate to a newcomer though.  There are the
>> paths I see, the paths the chroot is going to see, then paths used as
>> prefix and lib-path.  At couple diagrams might help in the beginning.
>> I'm still stuck on binutils, chapter 5,
>> http://www.linuxfromscratch.org/lfs/view/stable/chapter05/binutils-pass1.html
>>
>> I started out making a mountpoint called /lfs to mount the partition
>> I'm working in, then decided it was a bad idea.  What I have looks
>> like:
>>
>> /lost+found
>> /media
>> /mnt
>>    lfs
>>      sources
>>        binutils-2.30
>>          build
>>      tools
>> /opt
>> /proc
>>
>> Filezilla has nice directory trees BTW if somebody wants to do
>> screenshots for documenting.  :)  Anyway I'm not sure that's right.
>> Does the page mean to make build inside of binutils or is it outside
>> to be used again later?  My $LFS is set to /mnt/lfs
>>
>> I made a little cfg script for consistency rather than doing it from
>> memory, it's mostly copied from the web page:
>> #!/bin/sh
>> ../configure --prefix=/tools            \
>>    --with-sysroot=$LFS        \
>>    --with-lib-path=/tools/lib \
>>    --target=$LFS_TGT          \
>>    --disable-nls              \
>>    --disable-werror
>>
>> configure echos it back as
>>   ../configure --prefix=/tools --with-sysroot=/mnt/lfs
>> --with-lib-path=/tools/lib --target=aarch64-lfs-linux-gnu
>> --disable-nls --disable-werror
>>
>> in the config.log.  OK, I'll attach the log.
>>
>> What worries me is the
>> gcc: error trying to exec 'as': execvp: Too many levels of symbolic links
>> In the conftest.  Debian has this kludgy alternatives system where gcc
>> is /usr/bin/gcc but that's
>> lrwxrwxrwx 1 root root 5 Apr  4 06:16 gcc -> gcc-7
>> and that's
>> lrwxrwxrwx 1 root root 23 Jun 26 03:52 gcc-7 -> aarch64-linux-gnu-gcc-7
>> And aarch64-linux-gnu-gcc-7 is the real name of gcc 7
>> maybe that's just part of conftest but configure dies with an error
>> and no makefile.  as is:
>> as -> aarch64-linux-gnu-as in /usr/bin
>>
>> These kludgy scripts, and PAM/Selinux/Apparmor are what I'm hoping to
>> get away from with linuxfromscratch.   Yes, I usually have a few gcc
>> and as and g++ versions around but it seems like there should be a
>> better way.
>>
>>    Alan
>>
>>
>>
> The build dir gose inside binutils.
> Untar package cd package dir follow book, always remove the used dir
> after you have built it.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.linuxfromscratch.org/pipermail/lfs-support/attachments/20180708/ddce0ab8/attachment-0001.html>
>
> ------------------------------
>
> Message: 4
> Date: Sun, 8 Jul 2018 18:15:52 +0100
> From: spiky <spiky0011 at gmail.com>
> To: lfs-support at lists.linuxfromscratch.org
> Subject: Re: [lfs-support] Building LFS under Debian
> Message-ID: <80c57bda-9f1d-3262-b780-66081e5df7c2 at gmail.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
>
>
> On 08/07/18 17:25, Alan Corey wrote:
>> LFS is a work of art, I can't believe it's been around 20 years and
>> I'd never heard of it.  20 years ago I was downloading Slackware on
>> floppies and lugging them home from college.
>>
>> The paths are sort of intricate to a newcomer though.  There are the
>> paths I see, the paths the chroot is going to see, then paths used as
>> prefix and lib-path.  At couple diagrams might help in the beginning.
>> I'm still stuck on binutils, chapter 5,
>> http://www.linuxfromscratch.org/lfs/view/stable/chapter05/binutils-pass1.html
>>
>> I started out making a mountpoint called /lfs to mount the partition
>> I'm working in, then decided it was a bad idea.  What I have looks
>> like:
>>
>> /lost+found
>> /media
>> /mnt
>>    lfs
>>      sources
>>        binutils-2.30
>>          build
>>      tools
>> /opt
>> /proc
>>
>> Filezilla has nice directory trees BTW if somebody wants to do
>> screenshots for documenting.  :)  Anyway I'm not sure that's right.
>> Does the page mean to make build inside of binutils or is it outside
>> to be used again later?  My $LFS is set to /mnt/lfs
>>
>> I made a little cfg script for consistency rather than doing it from
>> memory, it's mostly copied from the web page:
>> #!/bin/sh
>> ../configure --prefix=/tools            \
>>    --with-sysroot=$LFS        \
>>    --with-lib-path=/tools/lib \
>>    --target=$LFS_TGT          \
>>    --disable-nls              \
>>    --disable-werror
>>
>> configure echos it back as
>>   ../configure --prefix=/tools --with-sysroot=/mnt/lfs
>> --with-lib-path=/tools/lib --target=aarch64-lfs-linux-gnu
>> --disable-nls --disable-werror
>>
>> in the config.log.  OK, I'll attach the log.
>>
>> What worries me is the
>> gcc: error trying to exec 'as': execvp: Too many levels of symbolic links
>> In the conftest.  Debian has this kludgy alternatives system where gcc
>> is /usr/bin/gcc but that's
>> lrwxrwxrwx 1 root root 5 Apr  4 06:16 gcc -> gcc-7
>> and that's
>> lrwxrwxrwx 1 root root 23 Jun 26 03:52 gcc-7 -> aarch64-linux-gnu-gcc-7
>> And aarch64-linux-gnu-gcc-7 is the real name of gcc 7
>> maybe that's just part of conftest but configure dies with an error
>> and no makefile.  as is:
>> as -> aarch64-linux-gnu-as in /usr/bin
>>
>> These kludgy scripts, and PAM/Selinux/Apparmor are what I'm hoping to
>> get away from with linuxfromscratch.   Yes, I usually have a few gcc
>> and as and g++ versions around but it seems like there should be a
>> better way.
>>
>>    Alan
>>
>>
> Did you also run the version check script chapter 2.2?
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.linuxfromscratch.org/pipermail/lfs-support/attachments/20180708/67507eeb/attachment-0001.html>
>
> ------------------------------
>
> Message: 5
> Date: Sun, 8 Jul 2018 12:18:03 -0500
> From: Bruce Dubbs <bruce.dubbs at gmail.com>
> To: lfs-support at lists.linuxfromscratch.org
> Subject: Re: [lfs-support] Building LFS under Debian
> Message-ID: <d2ead953-560e-21dc-1939-c24d4dc9684b at gmail.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 07/08/2018 11:25 AM, Alan Corey wrote:
>> LFS is a work of art, I can't believe it's been around 20 years and
>> I'd never heard of it.  20 years ago I was downloading Slackware on
>> floppies and lugging them home from college.
>>
>> The paths are sort of intricate to a newcomer though.  There are the
>> paths I see, the paths the chroot is going to see, then paths used as
>> prefix and lib-path.  At couple diagrams might help in the beginning.
>> I'm still stuck on binutils, chapter 5,
>> http://www.linuxfromscratch.org/lfs/view/stable/chapter05/binutils-pass1.html
>>
>> I started out making a mountpoint called /lfs to mount the partition
>> I'm working in, then decided it was a bad idea.  What I have looks
>> like:
>>
>> /lost+found
>> /media
>> /mnt
>>    lfs
>>      sources
>>        binutils-2.30
>>          build
>>      tools
>> /opt
>> /proc
>
> 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.
>
>> Filezilla has nice directory trees BTW if somebody wants to do
>> screenshots for documenting.  :)  Anyway I'm not sure that's right.
>> Does the page mean to make build inside of binutils or is it outside
>> to be used again later?  My $LFS is set to /mnt/lfs
>
> It should be inside.  One issue that trips many up is that the
> procedures in Section 5.3:
>
> untar
> cd
> follow instructions as written
> cd back to sources
> rm expanded directory
>
> Every time.
>
> Another thing that trips up new users is doing some things as root.  The
> LFS environment variable needs to be set for root also.  See the caution
> in Sectipn 2.6. Setting The $LFS Variable.
>
>
>> I made a little cfg script for consistency rather than doing it from
>> memory, it's mostly copied from the web page:
>> #!/bin/sh
>> ../configure --prefix=/tools            \
>>    --with-sysroot=$LFS        \
>>    --with-lib-path=/tools/lib \
>>    --target=$LFS_TGT          \
>>    --disable-nls              \
>>    --disable-werror
>>
>> configure echos it back as
>>   ../configure --prefix=/tools --with-sysroot=/mnt/lfs
>> --with-lib-path=/tools/lib --target=aarch64-lfs-linux-gnu
>> --disable-nls --disable-werror
>
> We do not test LFS on an ARM processor.  What you have above looks OK,
> but I cannot say the system will be built properly or not.  I suggest
> double checking the host system requirements (Section 2.2).
>
>> in the config.log.  OK, I'll attach the log.
>>
>> What worries me is the
>> gcc: error trying to exec 'as': execvp: Too many levels of symbolic links
>> In the conftest.  Debian has this kludgy alternatives system where gcc
>> is /usr/bin/gcc but that's
>> lrwxrwxrwx 1 root root 5 Apr  4 06:16 gcc -> gcc-7
>> and that's
>> lrwxrwxrwx 1 root root 23 Jun 26 03:52 gcc-7 -> aarch64-linux-gnu-gcc-7
>> And aarch64-linux-gnu-gcc-7 is the real name of gcc 7
>> maybe that's just part of conftest but configure dies with an error
>> and no makefile.  as is:
>> as -> aarch64-linux-gnu-as in /usr/bin
>
> Those symlinks are probably OK. Debian uses the same thing on x86_64.
>
>    -- Bruce
>
>> These kludgy scripts, and PAM/Selinux/Apparmor are what I'm hoping to
>> get away from with linuxfromscratch.   Yes, I usually have a few gcc
>> and as and g++ versions around but it seems like there should be a
>> better way.
>>
>>    Alan
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> --
> http://lists.linuxfromscratch.org/listinfo/lfs-support
> FAQ: http://www.linuxfromscratch.org/blfs/faq.html
> Unsubscribe: See the above information page
>
>
> ------------------------------
>
> End of lfs-support Digest, Vol 969, Issue 1
> *******************************************
>


-- 
-------------
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach


More information about the lfs-support mailing list