Compile custom kernel 13.4 release fails

Trying to compile a custom kernel to get ALTQ with PF.
My kernel.conf:
Code:
include GENERIC
ident MYKERNEL

options     ALTQ            # PF quality of service queues
options     ALTQ_CBQ        # Class Based Queueing
options     ALTQ_PRIQ       # Priority Queueing
options     ALTQ_HFSC       # Hierarchial Packet Scheduler

Is the source updated when security patches are applied?

Code:
# uname -a
FreeBSD xxx 13.4-RELEASE-p3 FreeBSD 13.4-RELEASE-p3 GENERIC amd64

I haven't built a custom kernel in ages, so not sure what's up.
It's complaining about inconsistencies between code and the headers, which seems to be true:
Do I need to update something?

Code:
/usr/src/sys/amd64/amd64/efirt.c:108:1: error: static declaration of 'efi_destroy_1t1_map' follows non-static declaration
  108 | efi_destroy_1t1_map(void)
      | ^
/usr/src/sys/sys/efi.h:179:6: note: previous declaration is here
  179 | void efi_destroy_1t1_map(void);
      |      ^
/usr/src/sys/amd64/amd64/efirt.c:115:7: error: no member named 'wire_count' in 'struct vm_page'; did you mean 'ref_count'?
  115 |                         m->wire_count = 0;
      |                            ^~~~~~~~~~
      |                            ref_count
/usr/src/sys/vm/vm_page.h:243:8: note: 'ref_count' declared here
  243 |         u_int ref_count;                /* page references (A) */
      |               ^
/usr/src/sys/amd64/amd64/efirt.c:116:24: error: use of undeclared identifier 'vm_cnt'
  116 |                 atomic_subtract_int(&vm_cnt.v_wire_count,
      |                                      ^
/usr/src/sys/amd64/amd64/efirt.c:187:1: error: static declaration of 'efi_create_1t1_map' follows non-static declaration
  187 | efi_create_1t1_map(struct efi_md *map, int ndesc, int descsz)
      | ^
/usr/src/sys/sys/efi.h:178:6: note: previous declaration is here
  178 | bool efi_create_1t1_map(struct efi_md *, int, int);
      |      ^
/usr/src/sys/amd64/amd64/efirt.c:300:8: error: assigning to 'int' from incompatible type 'void'
  300 |         error = fpu_kern_enter(curthread, NULL, FPU_KERN_NOCTX);
      |               ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/src/sys/amd64/amd64/efirt.c:433:19: error: invalid operands to binary expression ('void *' and 'unsigned long')
  433 |                         *ptr = (void *)PHYS_TO_DMAP(ct->ct_data);
      |                                        ^~~~~~~~~~~~~~~~~~~~~~~~~
./machine/vmparam.h:250:6: note: expanded from macro 'PHYS_TO_DMAP'
  250 |         (x) | DMAP_MIN_ADDRESS; })
      |         ~~~ ^ ~~~~~~~~~~~~~~~~
/usr/src/sys/amd64/amd64/efirt.c:442:1: error: no previous prototype for function 'efi_get_time_locked' [-Werror,-Wmissing-prototypes]
  442 | efi_get_time_locked(struct efi_tm *tm)
      | ^
/usr/src/sys/amd64/amd64/efirt.c:441:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
  441 | int
      | ^
      | static
/usr/src/sys/amd64/amd64/efirt.c:464:12: error: use of undeclared identifier 'resettodr_lock'
  464 |         mtx_lock(&resettodr_lock);
      |                   ^
/usr/src/sys/amd64/amd64/efirt.c:464:12: error: use of undeclared identifier 'resettodr_lock'
/usr/src/sys/amd64/amd64/efirt.c:466:14: error: use of undeclared identifier 'resettodr_lock'
  466 |         mtx_unlock(&resettodr_lock);
      |                     ^
/usr/src/sys/amd64/amd64/efirt.c:466:14: error: use of undeclared identifier 'resettodr_lock'
/usr/src/sys/amd64/amd64/efirt.c:471:1: error: conflicting types for 'efi_reset_system'
  471 | efi_reset_system(void)
      | ^
/usr/src/sys/sys/efi.h:186:5: note: previous declaration is here
  186 | int efi_reset_system(enum efi_reset type);
      |     ^
/usr/src/sys/amd64/amd64/efirt.c:484:1: error: no previous prototype for function 'efi_set_time_locked' [-Werror,-Wmissing-prototypes]
  484 | efi_set_time_locked(struct efi_tm *tm)
      | ^
/usr/src/sys/amd64/amd64/efirt.c:483:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
  483 | int
      | ^
      | static
/usr/src/sys/amd64/amd64/efirt.c:506:12: error: use of undeclared identifier 'resettodr_lock'
  506 |         mtx_lock(&resettodr_lock);
      |                   ^
/usr/src/sys/amd64/amd64/efirt.c:506:12: error: use of undeclared identifier 'resettodr_lock'
/usr/src/sys/amd64/amd64/efirt.c:508:14: error: use of undeclared identifier 'resettodr_lock'
  508 |         mtx_unlock(&resettodr_lock);
      |                     ^
/usr/src/sys/amd64/amd64/efirt.c:508:14: error: use of undeclared identifier 'resettodr_lock'
17 errors generated.
*** Error code 1

Stop.
make[4]: stopped in /usr/src/sys/modules/efirt
*** Error code 1
 
Your /usr/src tree and your system version may be incompatible with each other, i would suggest updating your /usr/src tree to the latest one together with your system or at least, to the one matching with your FreeBSD version (patch version, too.). I don't know what patch level is latest for 13.4, though.

EDIT: It seems that latest patch level is 4 for 13.4.


Make sure to checkout to releng/13.4 branch in /usr/src tree and update.
 
I haven't built a custom kernel in ages, so not sure what's up.
After updating source tree of releng/13.4 (and eventually system), set build target kernel-toolchain as a minimum requirement to build a (custom) kernel besides "buildworld":

build(7)
Code:
     kernel-toolchain  Rebuild the tools needed for kernel compilation.  Use
                       this if you did not do a buildworld first.


PS: Tested on a 14.2-RELEASE system, the buildkernel of a releng/13.4 source checkout builds just fine:
Code:
 # make -j <n> kernel-toolchain &&  make -j <n> buildkernel KERNCONF=134KERNEL
134KERNEL = kernel.conf
 
Your /usr/src tree and your system version may be incompatible with each other, i would suggest updating your /usr/src tree to the latest one together with your system or at least, to the one matching with your FreeBSD version (patch version, too.). I don't know what patch level is latest for 13.4, though.

EDIT: It seems that latest patch level is 4 for 13.4.


Make sure to checkout to releng/13.4 branch in /usr/src tree and update.
Is there a way to verify the integrity of /usr/src/ files, rather than deleting and doing a git clone and having to merge /etc and others?

In any case, it appears 13_4 won't buildworld:
Code:
cd /usr
#  mv src src_13_4_20250314
# git clone -b releng/13.4 --depth 1 https://git.freebsd.org/src.git /usr/src
# cd src
# git config full.ff only
# git pull 
#  says: Already up to date.
# cd ..
# mv obj obj_20230519
# cd src
# make buildworld
...
===> etc/sendmail (all)
find: /usr/local/share/sendmail/cf: No such file or directory
make[4]: "/usr/src/etc/sendmail/Makefile" line 13: warning: "find /usr/local/share/sendmail/cf -type f -name '*.m4' -print" returned non-zero status
rm -f freebsd.cf
m4 -D_CF_DIR_=/usr/local/share/sendmail/cf/ -D_NO_MAKEINFO_    /usr/local/share/sendmail/cf/m4/cf.m4 /usr/src/etc/sendmail/freebsd.mc > freebsd.cf
m4: /usr/local/share/sendmail/cf/m4/cf.m4: No such file or directory
*** Error code 1
sendmail stuff is not in /usr/local/share/sendmail/; it is in /usr/share/sendmail/
There is no sendmail directory in /usr/local/share/ on either of my two fbsd 13.4 systems.
 
After updating source tree of releng/13.4 (and eventually system), set build target kernel-toolchain as a minimum requirement to build a (custom) kernel besides "buildworld":

build(7)
Code:
     kernel-toolchain  Rebuild the tools needed for kernel compilation.  Use
                       this if you did not do a buildworld first.


PS: Tested on a 14.2-RELEASE system, the buildkernel of a releng/13.4 source checkout builds just fine:
Code:
 # make -j <n> kernel-toolchain &&  make -j <n> buildkernel KERNCONF=134KERNEL
134KERNEL = kernel.conf
Does your 14.2-RELEASE system have a /usr/local/share/sendmail/ directory? I'm guessing it does because IRRC sendmail is not part of the base system in release 14, so you would have had to install the port -- in which case it would have contents in /usr/local/share/sendmail/. Does it build if you move that aside?
 
Is there a way to verify the integrity of /usr/src/ files, rather than deleting and doing a git clone ...
I believe there is none. The safest way to be sure is to clone a fresh source tree.

In any case, it appears 13_4 won't buildworld:
Are there make(1) or source build options set in make.conf, scr.conf, src-env.conf?

Also, to build only the kernel it's not necessary to "buildworld", "kernel-toolchain" is sufficient.


Does your 14.2-RELEASE system have a /usr/local/share/sendmail/ directory? I'm guessing it does because IRRC sendmail is not part of the base system in release 14, so you would have had to install the port -- in which case it would have contents in /usr/local/share/sendmail/. Does it build if you move that aside?
Building the system or kernel only from source doesn't rely on third party applications (mail/sendmail in this case).

Perhaps there are variables set on your system in make.conf, src.conf, src-env.conf, or other environment settings files, which would alter the build environment, because line 13 of /usr/src/etc/sendmail/Makefile is failing by looking for '*.m4' files under /usr/local, by default reserved for 3rd party application files installed by ports or packages, whereas base system sendmail source files are located under /usr/src/contrib/sendmail:
find: /usr/local/share/sendmail/cf: No such file or directory
make[4]: "/usr/src/etc/sendmail/Makefile" line 13: warning: "find /usr/local/share/sendmail/cf -type f -name '*.m4' -print" returned non-zero status

/usr/src/etc/sendmail/Makefile
Rich (BB code):
      8 SENDMAIL_DIR=   ${SRCTOP}/contrib/sendmail
      9 SMDIR=          ${SENDMAIL_DIR}/src
     10 SENDMAIL_CF_DIR?=${SENDMAIL_DIR}/cf
     11
     12 # this is overkill, but....
     13 M4FILES!=       find ${SENDMAIL_CF_DIR} -type f -name '*.m4' -print
SRCTOP = source root directory, in my test case /usr/src-13.4

Code:
 # ls /usr/src-13.4/contrib/sendmail/cf/m4
cf.m4      cfhead.m4  proto.m4   version.m4
 
I'm guessing it does because IRRC sendmail is not part of the base system in release 14
It's still included, but dma(8) is set as the default MTA. You can still switch back to sendmail. Heck, even 15-CURRENT still has it, although I do expect it will be removed before 15.0-RELEASE.
 
Are there make(1) or source build options set in make.conf, scr.conf, src-env.conf?
Ah, thanks. I had
Code:
SENDMAIL_CF_DIR= /usr/local/share/sendmail/cf
set in /etc/make.conf from an old issue. Forgot to comment it out when merging on an update I guess.

Also, to build only the kernel it's not necessary to "buildworld", "kernel-toolchain" is sufficient.
Not sure where I saw that. I thought in UPDATING but it only says kernel-toolchain. Thanks

Building the system or kernel only from source doesn't rely on third party applications (mail/sendmail in this case).
That's what I thought and why I was surprised by the sendmail issue.

Fixing make.conf seems to have solved the problem.

Am I right in assuming /usr/obj/ only contains things built from /usr/src/, and if git pull is used to refresh /usr/src/ the files in /usr/src/ will be dated more recently so make will over-write everything of relevance?
 
Fixing make.conf seems to have solved the problem.
Good to hear.

Am I right in assuming /usr/obj/ only contains things built from /usr/src/
That's correct.

and if git pull is used to refresh /usr/src/ the files in /usr/src/ will be dated more recently
not all files, only those files which are updated (replaced), added, dated according to the time of the system date.

Example:
Code:
 % find /usr/src-main -type f -exec ls -l {} + | grep 'Mar 18'
-rw-r--r--  1 root wheel   31181 Mar 18 20:50 /usr/src-main/Makefile
...

so make will over-write everything of relevance?
A repeated make will not overwrite but clean first what was created from previous build process, if not instructed to not do so by env variable or WITH_META_MODE enabled.

This is defined on all supported branches (not sure how far this goes back) in /usr/src/share/mk/src.opts.mk
Code:
59 __DEFAULT_YES_OPTIONS = \
...
83    CLEAN \

The 15 branch OTOH will not clean anymore
Code:
197 __DEFAULT_NO_OPTIONS = \
...
202     CLEAN \

build(7)
Code:
    clean        Remove any files created during the build process.
 
Assuming my original problem was the result of a configuration option in /etc/make.conf, I don't see any reason to put /usr/src/ under git control. Is there an easy way to undo putting things under git control? I tried moving /usr/src/ aside and doing a mkdir src; freebsd-update fetch but got the message "src component not installed, skipped", although I have src as a Component in /etc/freebsd-update.conf.
 
mkdir src; freebsd-update fetch but got the message "src component not installed, skipped", although I have src as a Component in /etc/freebsd-update.conf.
The default system source directory is only updated by freebsd-update(8) when /usr/src is populated. You can re-use the GIT cloned /usr/src directory. Make sure the branch is the same as the systems.

If space is an factor, one can delete /usr/src/.git directory.

To start with a fresh /usr/src, extract a src.txz distribution file from a installation media ( /usr/freebsd-dist/src.txz ) or direct download from a official FreeBSD remote repository.

For example 13.4-RELEASE (size ~ 205M): https://download.freebsd.org/releases/amd64/13.4-RELEASE/src.txz

Or a patched archive, currently 13.4-p4: https://github.com/freebsd/freebsd-src/archive/refs/tags/release/13.4.0-p4.tar.gz

The difference between a GIT cloned repository and this src.txz distribution file is it lacks the administrative files directory .git/ and its files. Installation images ( *.iso, *.img, etc.) are build without it:

src/release/Makefile
Rich (BB code):
2 # Makefile for building releases and release media.
...
135 src.txz:
136    mkdir -p ${DISTDIR}/usr
137    ln -fs ${WORLDDIR} ${DISTDIR}/usr/src
138    cd ${DISTDIR} && tar cLvf - --exclude .svn --exclude .zfs \
139        --exclude .git --exclude @ --exclude usr/src/release/dist usr/src | \
140        ${XZ_CMD} > ${.OBJDIR}/src.txz
 
Some additional remarks:
Is there an easy way to undo putting things under git control?
Yes, there is:
Code:
# cd /usr/src
# rm -rf \.git

Note that the sources when under control by freebsd-update(8) (you need an appropriately set freebsd-update.conf(5), as you noted) are not identical as those put there (by you 'manually') by using git; think git 'administrative files'. Sources under freebsd-update control are, as far as the base is concerned, mostly for (human) reading reference as I understand it, and, also some of those files are needed to build ports from their sources (this was not immediately evident to me). If you want to build stuff in base, use git.

Being under 'git control' versus being under 'freebsd-update control' has different properties; see here for some further info.
 
Being under 'git control' versus being under 'freebsd-update control' has different properties; see here for some further info.
Thanks. I think for my purposes (ALTQ in PF), it's probably easier to set Components to "src world" and do the following:
Code:
# /etc/freebsd-update.conf Components="src world"
freebsd-update fetch
make kernel-toolchain
make KERNCONF=MYKERNEL
freebsd-update install
make installkernel KERNCONF=MYKERNEL
reboot
Is that a reasonable sequence?
Or would it be better to leave Components set to "src world kernel" and do:
Code:
# /etc/freebsd-update.conf Components="src world kernel"
freebsd-update fetch
freebsd-update install
make kernel-toolchain
make KERNCONF=MYKERNEL
make installkernel KERNCONF=MYKERNEL
reboot
The point being to avoid running without the ALTQ capabilities in PF (i.e. no reboot until the rebuilt kernel is installed).
 
Back
Top