Compilation error on make kernel (11.1-RELEASE)

Hi everyone,

I'm having trouble compiling the kernel on my system. Used to work just fine, but shortly after the the patches for ipsec came out, the build would break on precisely that (see logs attached). World builds alright, though.

Tried cleaning up the source tree and /usr/obj, starting anew with a new checkout... I confess I am a bit puzzled (and feel quite stupid as well...). Must be something stupid...

My make.conf is empty, my last build dates from 13 March, and my kernelconf is GENERIC:

Code:
FreeBSD heinlein 11.1-RELEASE-p8 FreeBSD 11.1-RELEASE-p8 #0: Tue Mar 13 17:07:05 UTC 2018     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

Any ideas?
 

Attachments

  • make_buildkernel_logs.txt
    2.5 KB · Views: 231
It's been some time, maybe I mixed up the dates. The build date though comes straight from uname.

I've already done a clean checkout, but the build fails with the same error...
 
Did you change GENERIC or src.conf/make.conf in any way?
 
No, been relying on all the defaults for now.

Just launched another build this morning: removed all of /usr/src, /usr/obj, even rebooted (to avoid any stray ENV change I might have forgotten about), fresh checkout or releng/11.1, and exact same result following make buildworld (works) and make buildkernel (fails).

Must be missing something obvious, but really mystified, I confess.
 
Well, the adventure continues: since I had no luck with the kernel, I tried updating some ports. No joy here either, updating perl-5.24.3 to perl-5.24.4 breaks as well (perl-5.24.4 is a dependency of firefox 60, which I was trying to upgrade to, from the version 59 currently installed).

Everything was fine the last time I updated stuff on this system (mid-march or so).

I'm attaching the logs from that build as well.

It's starting to not to look so good... but I'm not sure why...
 

Attachments

  • firefox_perl5_24_build_log.txt
    8.5 KB · Views: 268
Reboot in single user mode and do

fsck -y /dev/each_drive_partition

The above command must be launched twice at a minimum, until you get a final "clean" result

Sometime the file system is marked as clean, and process ends up quickly with a very superficial check process, but file system is not really clean.

Launching a second time the command will force a deep check. This is the reason why I specify "twice" at a minimum.

Now reboot and log, backup and regenerate a brand new /usr/src


mv /usr/src /usr/src-old
mkdir /usr/src
svn co https://svn0.us-west.freebsd.org/base/releng/11.1 /usr/src
svn update /usr/src


I have many time experienced in the past some unrecoverable and invisible corruptions in /usr/src that 'svn' is unable to detect and repair. It happens especially if you use UFS2 without the only one good protection Gjournal.

UFS2 + Softupdate + UFS Journal is a B ..... H I T.
I have lost in the past several systems before switching to UFS2 + gjournal

It also happens on USB drives

You may possibly have to rebuild and install the world before trying to rebuild kernel,
Indeed, if /usr/src was corrupt there are possibly and even great chances that "world" is also corrupt.

Anyway, if you want to build only kernel you can do as follow.
Just think to regenerate before the kernel tool chain which is possibly corrupt


cd /usr/src
make kernel-toolchain
make kernel && make installkernel


if you finally decide to rebuild the world


cd /usr/src
make toolchain
make buildworld && make installworld


If you were running UFS2 without Gjournal either switch to ZFS or UFS2 + Gjournal

Again... UFS2 without gjournal is a real B ...... H I T
I am playing with FreeBSD since version 8 so now I have a little experience. If you don't switch, you will experience data corruptions again and again in the future.

In fact it depends on the hardware and also if you use jails that may generate a complex I/O drive data flows.
UFS2 is basically a big data server grade filesystem, not a workstation filesystem.
So it is assumed to run on high grade disk controllers.... and this is not allways the case in the common PC

So sometimes with some classes of controller, UFS2 works badly and needs Gjournal to reduce drastically errors
For example, I have some old HP Business Desktops with Intel ICH8/9 chips setup in RAID0 with a FreeBSD running 7 jails ... this is simply a nightmare without gjournal

But some other people will claim here having no issue with UFS2 in standard setup, but they all have quite different hardwares. Some other people think to have no problem and no use of Gjournal, until the day ...

It is a known problem of UFS which is very sensible to the quality of the disk controllers
NTFS, Ext4 are far more permissive.
 
Thanks for the very long and detailed answer. I use ZFS, but since I don't have any redundancy, I double checked the pool (zpool scrub), and found no error.

Tried another time, just with the toolchain, as suggested, to no avail.
I've seen mentions in UPDATING of the new ld (lld) being required. Even though it doesn't make much sense (as the error is a compilation error), I've tried that as well (make LD=ld.lld buildkernel), still with no success.

The last option seems to build and install world and only then attempt to build the kernel, but I'm quite surprised this would be needed. I confess I've never done that before and all the docs I've read so far always talk about installing the kernel first. I'm a bit afraid to end up with a system taht can't even boot anymore. Have you tried installing world first in the past?
 
I got the thing working, but if someone can help me understand where I missed a step, I would be very grateful.

To sum up, the error was that the compiler would encounter a call to a function it's never seen before, ipsec_support_enable (and same thing with ipsec_support_disable), in the file sys/netipsec/ipsec_mod.c. This function is declared in ipsec_support.h, only if IPSEC_SUPPORT is defined. Given how the header is written, defining only IPSEC is not enough, but defining IPSEC in addition to IPSEC_SUPPORT will have the effect of skipping that bit of code.

I ended up building a custom kernel, commenting out the option IPSEC and adding IPSEC_SUPPORT. Only then did I get the kernel to compile.

I assume everyone here can make a clean checkout and compile a GENERIC kernel with no issue... I must have done something wrong at some point, but I honestly can't see what exactly. Has anyone any idea what went wrong?

Thanks all for you help!

Now, I need to install the thing is see it boot, but what could possibly go wrong? :)
 
Interestingly, the GENERIC I just checked out yesterday from svn is different from that on GitHub on that particular aspect: in SVN, I have only IPSEC, on GitHub, I see IPSEC and IPSEC_SUPPORT in GENERIC.

Is my checkout (disk?) at fault here?

Code:
rm -rf /usr/src/*
rm -rf /usr/src/.arc*
rm -rf /usr/src/.svn
svn checkout https://svn.freebsd.org/base/releng/11.1 /usr/src

Confused...
 
GitHub ? That got me confused a bit ..

But as you're using zfs it might be worth checking this issue out from scratch, i.e. do a fresh install, reboot there, fetch /usr/src and build world and kernel.
E.g. if your current boot is rpool/ROOT/11.1 you can create new fileset rpool/ROOT/fresh, mount it, unpack all necessary basic packages to this new mountpoint and reboot to it. Then try it again. This way you'll know if the problem is local to your current setup or something else.
 
What I mean is that is you look in the GitHub repository for FreeBSD, you can see that GENERIC has had since August 2017 both IPSEC and IPSEC_SUPPORT (following this commit in current, or that one in stable/11).

I don't think RELEASE branches are mirrored in GitHub, though. Looking straight in the svn repository, I see that GENERIC is missing IPSEC_SUPPORT (so my checkout itself is not at fault, I get what's actually there).

Now, what I'm confused about is how is IPSEC/IPSEC_SUPPORT supposed to work? Reading ipsec_support.h, they seem exclusive, as on line 143, the condition to define module attaching functions for the ipsec module are only defined if IPSEC itself is not defined:

Code:
LINE 115

#if defined(IPSEC)
struct ipsec_support {
    const u_int enabled;
    const struct ipsec_methods * const methods;
};
extern const struct ipsec_support * const ipv4_ipsec_support;
extern const struct ipsec_support * const ipv6_ipsec_support;
... code code ...

LINE 143
#elif defined(IPSEC_SUPPORT)
struct ipsec_support {
    volatile u_int enabled;
    const struct ipsec_methods * volatile methods;
};
extern struct ipsec_support * const ipv4_ipsec_support;
extern struct ipsec_support * const ipv6_ipsec_support;

void ipsec_support_enable(struct ipsec_support * const,
    const struct ipsec_methods * const);
void ipsec_support_disable(struct ipsec_support * const);

int ipsec_kmod_input(struct ipsec_support * const, struct mbuf *, int, int);
int ipsec_kmod_check_policy(struct ipsec_support * const, struct mbuf *,
    struct inpcb *);
... code code ...

Does anyone know? Do you have both IPSEC and IPSEC_SUPPORT in your kernel configuration? Does it work? Is ipsec a module, then?

For clarity, I believe what confuses me here is: if GENERIC doesn't have IPSEC_SUPPORT, how come the module is being built in the first place?

Thanks for the idea of playing with ZFS to sort it out, I'll try to give it a go next weekend.
 
OK, now I understand what you meant with GitHub. I never checked out FreeBSD sources from GitHub though. I always use their svn repositories.
I have IPSEC enabled in my custom kernel, but not IPSEC_SUPPORT.

You can change the behavior of what is built with make buildkernel in make.conf(5). Man page describes those options. By default all modules are built.
 
Back
Top