"make" in ports tells me "requires kernel source files in SRC_BASE=/usr/src." despite an up-to-date /usr/src

[Michael Schuster]

On Mon, Feb 8, 2021 at 6:08 PM Oleg V. Nauman <oleg at theweb.org.ua> wrote:

> On 2021 M02 8, Mon 09:01:26 EET Yuri Pankov wrote:
> > Michael Schuster wrote:
> > > Hi,
> > >
> > > again, apologies if this is not the right place to ask this question
> ...
> > >
> > > I've done a fair amount of googling, without relevant findings.
> > >
> > > $Subject says all - both the port I'm trying to build as well as
> /usr/src
> > > are up-to-date (one using "svn up", the other "git pull"), I'm also
> > > running
> > > the kernel that I built from those sources.
> > >
> > > uname:
> > > FreeBSD host 14.0-CURRENT FreeBSD 14.0-CURRENT #12
> > > main-n244657-344f1083e12: Sat Feb  6 12:17:33 CET 2021
> > > root at host:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
> > >
> > >   amd64
> >
> > FWIW, I am not seeing the issue.  Having said that, the trailing dot
> > after /usr/src in that error message looks suspicious, it is not there
> > in /usr/ports/Mk/Uses/kmod.mk; was that an exact copy/paste?  If yes,
> > check if you are (incorrectly) setting SRC_BASE somewhere?
>
>  It is a bug in /etc/rc.d/linux script
>

actually, in my case it was ... I don't quite know what.
You may have seen I use "DESTDIR=/mnt", which is the mountpoint for a newly
created boot environment:

$ bectl list
BE                             Active Mountpoint Space Created
[...]
BE_20210206_175312_CURRENT14   NR     /          30.8G 2021-02-06 17:53
BE_20210208_204901_CURRENT_14  -      /mnt       860K  2021-02-08 20:49

... which, as I found out, does NOT include /usr/src; only after creating a
snapshot of same and mounting that specifically:

$ sudo mount -t zfs tank/usr/src at 20210208 /mnt/usr/src

... did my make command work.

Thx to all who helped me think about this properly :-)
Michael

PS: I'll be researching this boot env. behaviour a bit more (I was the same
using bectl or beadm), should someone have an idea already, I'm all ears!



> linux_start()
> {
>         local _emul_path _tmpdir
>         _emul_path="$(sysctl -n compat.linux.emul_path)"
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   Attempt to use of "sysctl -n compat.linux.emul_path" value when it is
> not
> available because we are loading 'linux64.ko' later. It means that
> _emul_path
> contains empty data.
>
>
>         load_kld -e 'linux(aout|elf)' linux
>         case `sysctl -n hw.machine_arch` in
>         amd64)
>                 load_kld -e 'linux64elf' linux64
>                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   Actual load of linux64 kernel module
>
> .................................
> and later..
>
>
>         if checkyesno linux_mounts_enable; then
>                 mount -o nocover -t linprocfs linprocfs
> "${_emul_path}/proc"
>                 mount -o nocover -t linsysfs linsysfs "${_emul_path}/sys"
>                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>  _emul_path is empty so it will run
> mount -o nocover -t linsysfs linsysfs "/sys"
> while
> # ls -dl /sys
> lrwxr-xr-x  1 root  wheel  11 Jun  4  2018 /sys -> usr/src/sys
> symlink to /usr/src/sys
> It will effectively hide actual content of /usr/src/sys if you have
> linux_enable="YES", causing build failure of any port with kernel modules.
>
> Thank you
>
>
>
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "
> freebsd-questions-unsubscribe at freebsd.org"
>


-- 
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'