Re: llvm10 build failure on Rpi3

From: Mark Millard via freebsd-ports <freebsd-ports_at_freebsd.org>
Date: Sat, 3 Jul 2021 18:59:25 -0700
On 2021-Jul-3, at 14:54, bob prohaska <fbsd at www.zefox.net> wrote:

> On Sat, Jul 03, 2021 at 01:15:19PM -0700, Mark Millard wrote:
>> 
>> 
>> 
>> So you still have not tried an artifacts or snapshot kernel+world?
>> 
> Not yet. 
> 
>>> Eventually I resorted to running make in devel/llvm10, to my surprise it
>>> ran to completion.
>> 
>> Interesting.
>> 
>> Was this -j4? -j1? -j2? Any other interesting characteristics
>> for how it was run?
>> 
> Nothing special was done. IIRC, it was make -DBATCH > make.log in
> the background. From top's screen it looked like -j4. 
> 
>> It would be interesting to see if building in a chroot
>> in that make style also worked (or a non-poudriere jail).
>> 
> 
> Can you point me to instructions for doing the experiment?

I tend to presume operation from a root login so I've nothing
about managing user account vs. root account ownerships and
the like. I pick names and places for things to make the
example.

# cd /usr/src/
# mkdir -p ~/chroot-system/
# make installworld DESTDIR=~/chroot-system/ DB_FROM_SRC=1
# make distrib-dirs DESTDIR=~/chroot-system/ DB_FROM_SRC=1
# make distribution DESTDIR=~/chroot-system/ DB_FROM_SRC=1

One could expand artifacts.ci.freebsd.org *.txz materials
into ~/chroot-system/ instead. The above is just one way
of populating ~/chroot-system/ initially.

For now, I will not show later updating to a newer system
in ~/chroot-system/ . There are more choices to make for
what, if anything, should be preserved or adjsuted by such
an update.

The following definitions do not survive RPI* reboots . . .

# mount -tdevfs devfs ~/chroot-system/dev
# mkdir -p ~/chroot-system/usr/src/ ~/chroot-system/usr/ports/
# mount_nullfs /usr/src ~/chroot-system/usr/src
# mount_nullfs /usr/ports ~/chroot-system/usr/ports

The ~/chroot-system/dev is what allows /dev/null and
other such to work in  the chroot context.

Instead of nullfs mounts you could establish independent
instances. ~/chroot-system/usr/src/ should track whatever
world was put inside ~/chroot-system/ .

Use via . . .

(You may have tailoring of the environment that you want
to set up in the chroot. I do not show anything for that.
This could include things like setting up /etc/make.conf
and /etc/src.conf files in the chroot.)

# chroot ~/chroot-system/
# pwd
/
# . . .
# cd /usr/ports/devel/llvm10/
# make . . .
. . .
# exit

Until you exit from the chroot, you will not see the file
system that is outside ~/chroot-system/ (other than via the
special mounts that were set up earlier above). From the
overall system view that / in the chroot's operation is
implicitly a reference to ~/chroot-system/ as if it was a
root file system. Inside the chroot, ~/ is a reference
to a different place than it was outside the chroot.

Note that even pkg will have to be bootstrapped as if this
was a separate, new root filesystem.

I'll note that modern main can have chroot worlds that are
stable/13 or releng/13 based instead of main based (a
releng/13 example from my context):

# uname -apKU
FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #7 main-n247651-a00d703f2f43-dirty: Wed Jun 30 15:11:11 PDT 2021     root_at_CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72  arm64 aarch64 1400024 1300139

On the aarch64 RPi*'s the world could even be arm.armv7
based instead of arm64.aarch64 based (stable/13 example):

# uname -apKU
FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #7 main-n247651-a00d703f2f43-dirty: Wed Jun 30 15:11:11 PDT 2021     root_at_CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72  arm armv7 1400024 1300510

I'll note that deleting ~/chroot-system from ouside the
chroot is a 2 step process because of some special file
protections:

# chflags -R noschg ~/chroot-system/
# rm -fr ~/chroot-system

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Received on Sun Jul 04 2021 - 01:59:25 UTC

Original text of this message