# FreeBSD 9.3 Buildkernel errors and warnings



## bsduni (Feb 13, 2015)

Hi,

I m learning some kernel customizing skills and as the first step I tried to build a kernel with a custom name by copying the GENERIC to MYKERN1 on a machine with FreeBSD 9.3. Even though the `# make buildkernel KERNCONF=MYKERN1` succeeds, the following errors and warnings are thrown.


```
root@silvereye:/usr/src # make buildkernel KERNCONF=MYKERN1 > /home/bsduni/patching/orig-buildkernel.txt
./aicasm: 880 instructions used
./aicasm: 826 instructions used
../aicasm/aicasm: 880 instructions used
../aicasm/aicasm: 826 instructions used
ERROR: ctfconvert: rc = 2 No entry found [dwarf_next_cu_header(57)]
WARNING: kern_clock.c: enum pmc_event has too many values: 1601 > 1023
WARNING: kern_lock.c: enum pmc_event has too many values: 1601 > 1023
WARNING: kern_mutex.c: enum pmc_event has too many values: 1601 > 1023
WARNING: kern_pmc.c: enum pmc_event has too many values: 1601 > 1023
WARNING: kern_rwlock.c: enum pmc_event has too many values: 1601 > 1023
WARNING: kern_sx.c: enum pmc_event has too many values: 1601 > 1023
ERROR: ctfconvert: file does not contain dwarf type data (try compiling with -g)
ERROR: ctfconvert: file does not contain dwarf type data (try compiling with -g)
ERROR: ctfconvert: file does not contain dwarf type data (try compiling with -g)
ERROR: ctfconvert: file does not contain dwarf type data (try compiling with -g)
ERROR: ctfconvert: file does not contain dwarf type data (try compiling with -g)
WARNING: trap.c: enum pmc_event has too many values: 1601 > 1023
ERROR: ctfconvert: file does not contain dwarf type data (try compiling with -g)
ERROR: ctfconvert: file does not contain dwarf type data (try compiling with -g)
ERROR: ctfconvert: file does not contain dwarf type data (try compiling with -g)
ERROR: ctfconvert: rc = 2 No entry found [dwarf_next_cu_header(57)]
ERROR: ctfconvert: rc = 2 No entry found [dwarf_next_cu_header(57)]
ERROR: ctfconvert: rc = 2 No entry found [dwarf_next_cu_header(57)]
WARNING: hwpmc_mod.c: enum pmc_event has too many values: 1601 > 1023
WARNING: hwpmc_logging.c: enum pmc_event has too many values: 1601 > 1023
WARNING: hwpmc_soft.c: enum pmc_event has too many values: 1601 > 1023
WARNING: hwpmc_amd.c: enum pmc_event has too many values: 1601 > 1023
WARNING: hwpmc_core.c: enum pmc_event has too many values: 1601 > 1023
WARNING: hwpmc_intel.c: enum pmc_event has too many values: 1601 > 1023
WARNING: hwpmc_piv.c: enum pmc_event has too many values: 1601 > 1023
WARNING: hwpmc_tsc.c: enum pmc_event has too many values: 1601 > 1023
WARNING: hwpmc_x86.c: enum pmc_event has too many values: 1601 > 1023
WARNING: hwpmc_uncore.c: enum pmc_event has too many values: 1601 > 1023
ERROR: ctfconvert: rc = 2 No entry found [dwarf_next_cu_header(57)]
ERROR: ctfconvert: file does not contain dwarf type data (try compiling with -g)
ERROR: ctfconvert: file does not contain dwarf type data (try compiling with -g)
ERROR: vxge.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 > 1023
ERROR: vxgehal-swapper.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 > 1023
ERROR: vxgehal-config.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 > 1023
ERROR: vxgehal-device.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 > 1023
ERROR: vxge-queue.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 > 1023
ERROR: vxgehal-mm.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 > 1023
ERROR: vxgehal-blockpool.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 > 1023
ERROR: vxgehal-channel.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 > 1023
ERROR: vxgehal-fifo.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 > 1023
ERROR: vxgehal-ring.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 > 1023
ERROR: vxgehal-virtualpath.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 > 1023
ERROR: vxgehal-doorbells.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 > 1023
ERROR: vxgehal-mgmt.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 > 1023
ERROR: vxgehal-mgmtaux.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 > 1023
ERROR: vxgehal-mrpcim.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 > 1023
ERROR: vxgehal-srpcim.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 > 1023
ERROR: vxgehal-ifmsg.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 > 1023
ERROR: ctfconvert: rc = 2 No entry found [dwarf_next_cu_header(57)]
ERROR: ctfconvert: file does not contain dwarf type data (try compiling with -g)
```

Any help to avoid such error messages?

For your information, I have a requirement to stick with FreeBSD 9.3 for the time being, and changing FreeBSD version is not a viable option at this stage.

Thank you in advance.


----------



## junovitch@ (Feb 14, 2015)

Given the size of the code, there's going to be errors. Adding a 2>&1 to the end of the command is the sh(1) to stick both stderr(4) and stdout(4) in the same log. For tcsh(1) using >& would do the same thing.


----------



## Terry_Kennedy (Feb 15, 2015)

bsduni said:


> Any help to avoid such error messages?
> 
> For your information, I have a requirement to stick with FreeBSD 9.3 for the time being, and changing FreeBSD version is not a viable option at this stage.



Make sure /usr/obj is empty before you do the build.
You might need to do a `# make buildworld; make installworld` first, particularly if you have downloaded updates to the kernel / system sources.
The script(1) utility will capture all terminal output to a disk log file (normally typescript, but you can specify a different name on the command line).
If none of those help, remove any customizations in /etc/make.conf, /etc/src.conf, etc. and restart at step 1.
If you're still stuck, do a `diff GENERIC MYKERN1` to see if you've removed a mandatory option or have a typo in your config file.


----------



## bsduni (Feb 16, 2015)

junovitch said:


> Given the size of the code, there's going to be errors. Adding a 2>&1 to the end of the command is the sh(1) to stick both stderr(4) and stdout(4) in the same log. For tcsh(1) using >& would do the same thing.



Thank you. As shown above, the above errors and warnings are part of stderr. 

In addition to the above errors, the system does not reboot normally with recompiled kernel. No login prompt appear (straight to the root without any verification) and no services work.


----------



## bsduni (Feb 16, 2015)

Terry_Kennedy said:


> Make sure /usr/obj is empty before you do the build.
> You might need to do a `# make buildworld; make installworld` first, particularly if you have downloaded updates to the kernel / system sources.
> The script(1) utility will capture all terminal output to a disk log file (normally typescript, but you can specify a different name on the command line).
> If none of those help, remove any customizations in /etc/make.conf, /etc/src.conf, etc. and restart at step 1.
> If you're still stuck, do a `diff GENERIC MYKERN1` to see if you've removed a mandatory option or have a typo in your config file.



Thank you Terry.

I have tried your the steps above and no changes. Errors and warnings continue. The system does not reboot normally with the recompiled kernel as expected. No login prompt appears - straight to the root without any verification, and no services work (e.g., no network connection).

GENERIC and MYKERN1 are the exact copies and no single file is changed. All the files under /usr/src are the exact copies from the FreeBSD 9.3 RELEASE amd64 disc and I tried again by deleting and copying all the source files from the disc.


----------



## Terry_Kennedy (Feb 16, 2015)

bsduni said:


> I have tried your the steps above and no changes. Errors and warnings continue. The system does not reboot normally with the recompiled kernel as expected. No login prompt appears - straight to the root without any verification, and no services work (e.g., no network connection).


This seems odd. Did you do a `# make installkernel`? If not, the new kernel should just be in /usr/obj and not installed.



> GENERIC and MYKERN1 are the exact copies and no single file is changed. All the files under /usr/src are the exact copies from the FreeBSD 9.3 RELEASE amd64 disc and I tried again by deleting and copying all the source files from the disc.


Ok, let's try one more thing. Do a `# make buildkernel` (without the KERNCONF stuff). That should build the stock GENERIC unless you have an override in /etc/make.conf. If that also fails, there's something else going on here.


----------



## junovitch@ (Feb 17, 2015)

bsduni said:


> ...
> No login prompt appears - straight to the root without any verification, and no services work (e.g., no network connection).
> ...



This on its own is just single user mode.  You would see this is there are disk issues that need a fsck(8) run to fix or there is another issue.  This doesn't make sense though in context here.  If you didn't change anything in the kernel configuration than nothing should have stopped it from booting.


----------



## bsduni (Feb 17, 2015)

Thank you Terry.

Sorry, it looks like I possibly missed one of the steps you mentioned.

Now, especially with `# make installworld`, which I didn't try before I started this thread, the compiled kernel works.

The following were the steps I followed in my last successful attempt:

```
# chflags -R noschg /usr/obj/*
# rm -rf /usr/obj
# cd /usr/src
# make -j4 buildworld
# make installworld
# make buildkernel KERNCONF=MYKERN1
# make installkernel KERNCONF=MYKERN1
```

Thank you all for the inputs.


----------



## junovitch@ (Feb 17, 2015)

Take a look at the Handbook for ordering.  A word of warning that updating binaries in world as you've shown above before you have a kernel that understands them could lead to unpredictable behavior.  Update the kernel first then the world.  See the Handbook for details.

https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html


----------



## Terry_Kennedy (Feb 18, 2015)

junovitch said:


> Take a look at the Handbook for ordering.  A word of warning that updating binaries in world as you've shown above before you have a kernel that understands them could lead to unpredictable behavior.  Update the kernel first then the world.  See the Handbook for details.
> 
> https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html


This should not be an issue when building the same version that is running, as the interfaces are specified as not changing (that's the very definition of -STABLE). I agree that if upgrading from FreeBSD x.* to FreeBSD y.* the full procedure as shown in the handbook should be used.


----------

