Can't build / install working kernel for 11.1-RELEASE-p10

U

urbanriot

Prior to today I was running a custom kernel with:
11.1-RELEASE-p6

Then I updated the source to:
11.1-RELEASE-p10

I built the kernel and probably should have filtered the output so I'd notice that there were a number of errors, but suffice to say the final version of the kernel resulted in a lot of issues like pf firewall not working.

I recompiled the kernel and had a pile of errors like this:

Code: 
/usr/src-stable/sys/dev/nvme/nvme.h:922:16: error: 
      taking address of packed member 'cdw10' of class or structure 
      'nvme_command' may result in an unaligned pointer value 
      [-Werror,-Waddress-of-packed-member] 
        *(uint64_t *)&cmd->cdw10 = lba;

s -mno-avx  -std=iso9899:1999 -Werror  /usr/src/sys/netpfil/pf/pf.c
/usr/src/sys/netpfil/pf/pf.c:4687:33: warning: taking address of packed member
      'ip_src' of class or structure 'ip' may result in an unaligned pointer
      value [-Waddress-of-packed-member]
                        pd2.src = (struct pf_addr *)&h2.ip_src;
                                                     ^~~~~~~~~
/usr/src/sys/netpfil/pf/pf.c:4688:33: warning: taking address of packed member
      'ip_dst' of class or structure 'ip' may result in an unaligned pointer
      value [-Waddress-of-packed-member]
                        pd2.dst = (struct pf_addr *)&h2.ip_dst;
                                                     ^~~~~~~~~
/usr/src/sys/netpfil/pf/pf.c:5472:47: warning: taking address of packed member
      'ip_src' of class or structure 'ip' may result in an unaligned pointer
      value [-Waddress-of-packed-member]
                        pf_map_addr(AF_INET, r, (struct pf_addr *)&ip->ip_src,
                                                                   ^~~~~~~~~~

I purged my source folder, downloaded 11.1-RELEASE, updated patches, and then made a clean kernel and I get the same errors.

Basically I can't seem to get my kernel to compile and the cause goes beyond my level of knowledge; Can anyone here help me?

Googling produces a number of hits with people having the same issue but no resolution. Thanks in advance!
 
Is there anything in /etc/make.conf and/or /etc/src.conf?
 
Yes to /etc/make.conf:
Code: 
ALLOW_UNSUPPORTED_SYSTEM=yes
CPUTYPE?=native
WITHOUT_X11=yes
WITHOUT_GUI=yes
WITHOUT_CUPS=yes
WITHOUT_MODULES=sound ntfs linux
OPTIONS_UNSET=CUPS FONTCONFIG X11
NO_AUTHPF=      true
NO_ATM=         true
NO_BLUETOOTH=   true
NO_FORTRAN=     true
NO_GAMES=       true
NO_GDB=         true
NO_GPIB=        true
NO_I4B=         true
NO_KERBEROS=    true
NO_LPR=         true
NO_MAILWRAPPER= true
NO_MODULES=     true
NO_NETCAT=      true
NO_NIS=         true
NO_SHAREDOCS=   true
NO_IPFILTER=    true
NO_BIND=                true
NO_BIND_DNSSEC=         true
NO_BIND_ETC=            true
NO_BIND_LIBS_LWRES=     true
NO_BIND_MTREE=          true
NO_BIND_NAMED=          true

No to /etc/src.conf

Do these
 
I suggest you remove everything from /etc/make.conf and try again. A whole bunch of them shouldn't even be in make.conf (almost all of the NO_* options have been deprecated a really long time ago).

But besides that, why are you running a custom kernel to begin with? There's rarely a reason for it nowadays. So I would recommend switching back to GENERIC and simply use freebsd-update(8) to keep everything updated.
 
SirDice said:
I suggest you remove everything from /etc/make.conf and try again. A whole bunch of them shouldn't even be in make.conf (almost all of the NO_* options have been deprecated a really long time ago).
Click to expand...

I've carried that make.conf through many kernel builds over the years and haven't reviewed it since, which I'll do shortly to determine which items are deprecated and which are not. However FreeBSD 11.1-RELEASE-p6 had no issues with these so something has changed between p6 and p10 where one of these variables is breaking a kernel compile.

As for why building a customer kernel, that's an odd question especially since it's in the FreeBSD handbook however the primary reason was it didn't make sense to compile into the kernel a majority of hardware that will never be used along with a significant list of options. That and it loads faster on a reboot off firmware when the kernel is slimmed down significantly.

I'll try a build without the make.conf
 
urbanriot said:
As for why building a customer kernel, that's an odd question especially since it's in the FreeBSD handbook
Click to expand...
Just because you can, doesn't mean you should.

urbanriot said:
That and it loads faster on a reboot off firmware when the kernel is slimmed down significantly.
Click to expand...
Most of the time a significant portion of the boot time is caused by the BIOS POST. It's really not going to decrease significantly, we're talking about a difference of a few milliseconds here. And from all the options you tried to disable through make.conf none of them actually have an influence on the kernel.
 
SirDice said:
And from all the options you tried to disable through make.conf none of them actually have an influence on the kernel.
Click to expand...

Of course, which is why the issue still exists.

I'm finding more people with the same errors on various forums, a few here, a few on pfsense forums, and elsewhere. Any other ideas on what's influencing these kernel compile errors?
 
Because a lot of users try to "optimize" things by adding all sorts of useless and dangerous options to make.conf. This may have been useful in the past, on modern FreeBSD versions however they're not needed and are likely to break things.
 
urbanriot said:
Of course, which is why the issue still exists.
Click to expand...
They won't have any influence on the kernel itself, no .. kernel build options aren't read from make.conf, but they could break something else, leading to your build problems.

I have to second SirDice here, disabling options for the kernel doesn't make any sense most of the time. Embedded systems or specially hardened configs could be exceptions.

It could make sense to disable options for the base system, but be careful here as well, it's easy to break the system. This can be done from make.conf, but src.conf would be the better place.
 
Few things to try, in order:
  • rm /etc/make.conf /etc/src.conf
  • make -C /usr/src/ clean
  • make -C /usr/src buildworld buildkernel
If you run into problems always try again with a clean build and try to build the GENERIC kernel. If GENERIC builds properly but your custom kernel does not the issue is most likely in your kernel config (typically caused by missing options or devices).
 
You must log in or register to reply here.
Back
Top