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



## urbanriot (May 20, 2018)

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:


```
/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!


----------



## SirDice (May 22, 2018)

Is there anything in /etc/make.conf and/or /etc/src.conf?


----------



## urbanriot (May 22, 2018)

Yes to /etc/make.conf:

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


----------



## SirDice (May 22, 2018)

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.


----------



## urbanriot (May 22, 2018)

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



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


----------



## SirDice (May 22, 2018)

urbanriot said:


> As for why building a customer kernel, that's an odd question especially since it's in the FreeBSD handbook


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.


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.


----------



## urbanriot (May 22, 2018)

SirDice said:


> And from all the options you tried to disable through make.conf none of them actually have an influence on the kernel.



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?


----------



## SirDice (May 22, 2018)

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.


----------



## zirias@ (May 22, 2018)

urbanriot said:


> Of course, which is why the issue still exists.


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.


----------



## urbanriot (May 23, 2018)

... personal philosophical beliefs aside, any insight into the actual errors?


----------



## Datapanic (May 23, 2018)

> I'll try a build without the make.conf



Well?


----------



## urbanriot (May 23, 2018)

urbanriot said:


> the issue still exists.


----------



## SirDice (May 23, 2018)

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


----------



## ShelLuser (May 23, 2018)

You purged your source folder, but what did you do with /usr/obj?

Skip this, and just follow SirDice message above me (I've been ninja'd  ).


----------

