Solved Error while compiling release 11 Custom Kernel after Spectre/Meltdown updates.

Hello Gentlemen,
Greetings.

I Can’t compile the stable 11 Kernel anymore after the changes related to Spectre/Meltdown.
Before it, I could compile it normally. I am not sure what I am missing. If some patch, if some Clang update/patch.

When compiling, I am getting errors like this one:
Code:
/tmp/FreeBSD-src/sys/amd64/amd64/support.S:829:2: error: unknown directive
.altmacro
^
<instantiation>:1:13: error: invalid register name
handle_ibrs_%(ll):
^~
Here is my OS and clang details:
Code:
root@freebsd:~ # uname -a
FreeBSD FreeBSD 11.1-RELEASE-p9 FreeBSD 11.1-RELEASE-p9 #0 r321309: Fri Jul 21 02:08:28 UTC 2017 [email]root@releng2.nyi.freebsd.org[/email]:/usr/obj/usr/src/sys/GENERIC amd64

root@freebsd:~ # clang -v
FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0)
Target: x86_64-unknown-freebsd11.1
Thread model: posix
InstalledDir: /usr/bin

Is there any update or patch I have to apply before compile it?

Any help will be greatly appreciated!
Thanks Much!

Fabricio.
 
I'm not sure clang 4.0.0 has support for the .altmacro. Have you tried to build the kernel-toolchain before doing a buildkernel? make kernel-toolchain
 
What's in /etc/make.conf? And what's the reason for the kernel compile in the first place? There's very little reason these days to build a custom kernel.
 
Because you're running a -RELEASE version and are using the GENERIC kernel I suggest you use freebsd-update(8) to update your machine.

Thanks for the message SirDice.
The freebsd-update was the first thing I did. it didn't fix it.

Here is a background: I am compiling a pfsense kernel (Fully based on Freebsd 11.1) - After the spectre/meltdown updates I see those errors involving "invalid arguments, etc" while compiling.

Here some more error messages:
Code:
ERROR: ctfconvert: t4fw_cfg.c: Couldn't read ehdr: Invalid argument
ERROR: ctfconvert: iwn2000fw.c: Couldn't read ehdr: Invalid argument
ERROR: ctfconvert: iwn135fw.c: Couldn't read ehdr: Invalid argument
I don't see anything really special at make.conf file but a few lines avoiding some features like:
Code:
WITHOUT_ACCT=YES
WITHOUT_AMD=YES
WITHOUT_APM=YES
WITHOUT_ASSERT_DEBUG=YES
WITHOUT_AT=YESWITHOUT_ATM=YES
WITHOUT_AUDIT=YES
WITHOUT_AUTHPF=YES
and here:
Code:
# Default serial console 
speedBOOT_COMCONSOLE_SPEED=115200
BOOT_BOOT0_COMCONSOLE_SPEED=0
I believe there is something wrong with my clang maybe (version?). Just wondering if you guys heard anything about it.

Thanks Much!
Fabricio.
 
PC-BSD, FreeNAS, NAS4Free, and all other FreeBSD Derivatives


You may not think some of the options are 'special' but I'm almost sure you have more than this in there. Please post the whole thing.


Hi SirDice,

I am aware of the pf forum, but please, forget about it. After netgate taking control of the project, your chances to get ANY help from them is ZERO. (at least to compile a custom kernel or compile the pfsense with a different "$product_name", since they changed the license model and you can't use pfsense name for a custom compilation)
I already asked on that forum. People who know how to make it didn't say a word. So, I would say pfsense is no longer that "opensource" app anymore.
That's why I am here (knowing the sources/kernel still freebsd).

Well, let me paste here the conf files I have. The building scripts are pointing to different conf files, so, here is what I got:
Code:
**FreeBSD-src/release/conf/pfSense_make.conf 
#HOSTAPD_CFLAGS+=-DEAP_PAX -DEAP_SAKE -DCONFIG_RSN_PREAUTH -DCONFIG_IEEE80211N
#HOSTAPD_CFLAGS+=-DEAP_SERVER -DEAP_GTC -DEAP_AKA -DEAP_SIM -DEAP_GPSK
#WPA_SUPPLICANT_CFLAGS+=-DCONFIG_IEEE80211N
# Default serial console speed
BOOT_COMCONSOLE_SPEED=115200
BOOT_BOOT0_COMCONSOLE_SPEED=0
Code:
**FreeBSD-src/release/conf/pfSense_installer_make.conf 
# Default serial console speed
BOOT_COMCONSOLE_SPEED=115200
BOOT_BOOT0_COMCONSOLE_SPEED=0
Code:
**FreeBSD-src/release/conf/pfSense_src-env.conf 
WITH_META_MODE=YES
WITHOUT_SYSTEM_COMPILER=YES
Code:
**FreeBSD-src/release/conf/pfSense_installer_src.conf 
WITHOUT_ACCT=YES
WITHOUT_AMD=YES
WITHOUT_APM=YES
WITHOUT_ASSERT_DEBUG=YES
WITHOUT_AT=YES
WITHOUT_ATM=YES
WITHOUT_AUDIT=YES
WITHOUT_AUTHPF=YES
WITHOUT_AUTOFS=YES
WITHOUT_BHYVE=YES
WITHOUT_BLACKLIST=YES
WITHOUT_BLUETOOTH=YES
WITHOUT_BSDINSTALL=YES
WITHOUT_BSNMP=YES
WITHOUT_CALENDAR=YES
WITHOUT_CAPSICUM=YES
WITHOUT_CASPER=YES
WITHOUT_CCD=YES
WITHOUT_CDDL=YES
WITHOUT_CPP=YES
WITHOUT_CTM=YES
WITHOUT_CUSE=YES
WITHOUT_DEBUG_FILES=YES
WITHOUT_DICT=YES
WITHOUT_EE=YES
WITHOUT_EXAMPLES=YES
WITHOUT_FILE=YES
WITHOUT_FINGER=YES
WITHOUT_FLOPPY=YES
WITHOUT_FMTREE=YES
WITHOUT_FREEBSD_UPDATE=YES
WITHOUT_FTP=YES
WITHOUT_GAMES=YES
WITHOUT_GCOV=YES
WITHOUT_GROFF=YES
WITHOUT_GSSAPI=YES
WITHOUT_HAST=YES
WITHOUT_HESIOD=YES
WITHOUT_HTML=YES
WITHOUT_HYPERV=YES
WITHOUT_ICONV=YES
WITHOUT_INETD=YES
WITHOUT_IPFILTER=YES
WITHOUT_IPFW=YES
WITHOUT_ISCSI=YES
WITHOUT_JAIL=YES
WITHOUT_KDUMP=YES
WITHOUT_KERBEROS=YES
WITHOUT_KERNEL_SYMBOLS=YES
WITHOUT_KVM=YES
WITHOUT_LANG=YES
WITHOUT_LDNS_UTILS=YES
WITHOUT_LIB32=YES
WITHOUT_LOCALES=YES
WITHOUT_LOCATE=YES
WITHOUT_LPR=YES
WITHOUT_LS_COLORS=YES
WITHOUT_MAIL=YES
WITHOUT_MAKE=YES
WITHOUT_MAN=YES
WITHOUT_NDIS=YES
WITHOUT_NETGRAPH=YES
WITHOUT_NIS=YES
WITHOUT_NLS=YES
WITHOUT_NLS_CATALOGS=YES
WITHOUT_NS_CACHING=YES
WITHOUT_NTP=YES
WITHOUT_PC_SYSINSTALL=yes
WITHOUT_PF=YES
WITHOUT_PKGBOOTSTRAP=YES
WITHOUT_PMC=YES
WITHOUT_PORTSNAP=yes
WITHOUT_PPP=YES
WITHOUT_PROFILE=YES
WITHOUT_QUOTAS=YES
WITHOUT_RADIUS_SUPPORT=YES
WITHOUT_RCMDS=YES
WITHOUT_RCS=YES
WITHOUT_RESCUE=YES
WITHOUT_ROUTED=YES
WITHOUT_SETUID_LOGIN=YES
WITHOUT_SHAREDOCS=YES
WITHOUT_SVNLITE=YES
WITHOUT_TALK=YES
WITHOUT_TCP_WRAPPERS=YES
WITHOUT_TCSH=YES
WITHOUT_TELNET=YES
WITHOUT_TESTS=yes
WITHOUT_TEXTPROC=YES
WITHOUT_TIMED=YES
WITHOUT_TOOLCHAIN=YES
WITHOUT_UNBOUND=YES
WITHOUT_USB_GADGET_EXAMPLES=YES
WITHOUT_VI=YES
WITHOUT_WIRELESS=YES
WITHOUT_WPA_SUPPLICANT_EAPOL=YES
**There is no /etc/make.conf file.

I have noticed most of the errors are happening while compiling files under "FreeBSD-src/sys/amd64/amd64/ " like support.S for example. (which I really believe it is the same one of the FreeBSD repository/github) - That's why I am wondering if nobody else had the same problem with a FreeBSD custom compilation.

I am also attaching the log generated during the compiling process. Maybe it helps much more.

I really appreciate the help.

Sincerely,
Fabricio.
 

Attachments

  • kernel.Kontrol.amd64.log.txt
    531.6 KB · Views: 406
A standard FreeBSD system compiles just fine.
SirDice,
Oh yeah, I am sure it does.

The question is: What is the minimum requirement to compile the "standard" Freebsd kernel with the most recent updates, including fix for spetre/meltdown?
Clang version? OS Version/patch level?

Thank You!!
Fabricio.
 
The question is: What is the minimum requirement to compile the "standard" Freebsd kernel with the most recent updates, including fix for spetre/meltdown?
Clang version? OS Version/patch level?
Just grab the latest supported version of FreeBSD and you should be fine. So at the time of writing that would be 10.4 or 11.1 ('Release'). Then check out the most current source tree from svn.freebsd.org and you're well on your way.

Don't forget that FreeBSD is pretty much a self-contained base system which provides all the tools you need. Building a kernel (or the OS itself) does not depend on external programs from the Ports collection.

Also see Chapter 8 of the FreeBSD handbook, /usr/src/README (briefly checking /usr/src/UPDATING is also advisable) and finally the FreeBSD developers handbook could also a good read but in all honesty it didn't do much for me when it came to building the kernel (and the base system). Still, it does contain good information about the source tree which can be useful.
 
Just came back to say that I found the problem. "Acheron" was right. CLANG 4 doesn't support .altmacro. After change to CLANG5/LLVM5 I could finally compile the Kernel with absolutelly no problems.
Thanks Everyone!

Fabricio.
 
I'm confused here and I can't help but wonder if you guys aren't mixing up your facts.

First: I'm assuming that we're talking about the patches which were propagated through the regular releases. I'm also assuming we're talking about RELEASE versions. The reason I say this is because the OP mentioned a "stable kernel" while showing they were using a release version (11.1-p9) (this is also mentioned in the subject).

But STABLE is a developer snapshot.

So here's my issue: you don't need LLVM5 for this on RELEASE, that's nonsense:
Code:
peter@zefiris:/home/peter $ uname -a
FreeBSD zefiris.intranet.lan 11.1-RELEASE-p9 FreeBSD 11.1-RELEASE-p9 #0 r333173: Thu May  3 11:08:54 CEST 2018     peter@unicron.intranet.lan:/usr/obj/usr/src/sys/UNICRON  amd64
peter@zefiris:/home/peter $ sysctl vm.pmap.pti
vm.pmap.pti: 1
peter@zefiris:/home/peter $ clang -v
FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0)
Target: x86_64-unknown-freebsd11.1
Thread model: posix
InstalledDir: /usr/bin
I build my system from source, both the base and kernel. As you can see the patches are applied and... LLVM4 is in effect here. No problem.

So either I'm misunderstanding something here or you didn't describe the actual situation. On a regular FreeBSD release (such as 11.1) you do not need anything else but the base system and the tools provided with them to get this build.
 
I'm not sure clang 4.0.0 has support for the .altmacro. Have you tried to build the kernel-toolchain before doing a buildkernel? make kernel-toolchain
You are the man!

It was first time on my long practice when I wasn't able to compile the kernel during freebsd-update. I don't know all that stuff about clang, but it doesn't sound logical to me that during binary update I have first to compile the world to be able to compile the kernel.
 
The sequence is always make buildworld buildkernel or make kernel-toolchain buildkernel. Either way a new C compiler must be built before the kernel compilation, the host compiler can't be trusted to be suitable for building the kernel because of the wild variation of different versions that might be used as the starting point for the upgrade.
 
The sequence is always make buildworld buildkernel or make kernel-toolchain buildkernel. Either way a new C compiler must be built before the kernel compilation, the host compiler can't be trusted to be suitable for building the kernel because of the wild variation of different versions that might be used as the starting point for the upgrade.

Sure it is so called official method, but why do I need the binary update at all if I would still need to seat and wait hours while world is built. That's what I meant. Previously I successfully jumped between even major releases many years, but here it was just between 11.1 and 11.2 . I don't blame anything and I don't know what can be done to simplify this, it's just doesn't look logical to me.

PS
Code:
make kernel-toolchain
was also very lengthy on the latest hardware with nvme disks.
 
Back
Top